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PRICING GRAPH REPRESENTATION FOR SETS OF PRICING 
SOLUTIONS FOR TRAVEL PLANNING SYSTEM 

BACKGROUND 

This invention relates to computerized travel 
planning systems . 

Travel planning systems are used to produce 
itineraries and prices by selecting suitable travel 
units from databases containing geographic, scheduling 
and pricing information. In the airline industry, 
fundamental travel units include "flights" (sequences of 
regularly scheduled takeoff s and landings assigned a 
common identifier) and "fares" (prices published by 
airlines for travel between two points) . The term 
"itinerary" is often used to refer to a sequence of 
flights on particular dates, and the term "pricing 
solution" is often used to refer to a combination of 
fares and itineraries that satisfies a 'travel request. 

The databases usually contain schedule information 
provided by airlines, typically in the so-called 
Standard Schedules Information Manual (SSIM) format, and 
usually fares published by airlines and resellers, 
typically provided through the intermediary Airline 
Tariff Publishing Company (ATPCO) . The database may 
also contain "availability" information that determines 
whether space is available on flights, or this may be 
obtained through communication links to external sources 
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such as airlines. 

Presently, so-called computer reservation system 
(CRSs) operate to produce fare and schedule information. 
There are four generally known computer reservation 
5 systems that operate in the United States, Sabre , 
Galileo , Amadeus and WorldSpan . The typical CRS 
contains a periodically updated central database that is 
accessed by subscribers such as travel agents through 
computer terminals. The subscribers use the computer 
10 reservation system to determine what airline flights are 
operating in a given market, what fares are offered and 
whether seats are available on flights to make bookings 
and issue tickets to clients. 

The computer reservation systems typically conduct 
15 searches using the information contained in the database 
to produce itineraries that satisfy a received request. 

The search results are sorted and returned to the 
requester s computer for display. Typically, the number 
of possible itineraries and pricing solutions that are 
20 returned by a CRS is a small portion of the total set 
that may satisfy a passengers request. 

SUMMARY 

25 

According to an aspect of the invention, a computer 
program product residing on a computer readable medium 
for determining a set of fares for a set of itineraries 
includes instructions for causing a computer to retrieve 
30 itinerary sets for at least one slice of a journey and 
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parse retrieved itinerary sets into faring atoms that 
correspond to one or more travel unit segments spanned 
by a single fare, wherein faring atoms are shared across 
itineraries. The product also includes instructions to 
5 cause the computer to apply rules to the faring atoms to 
produce fare components and construct from the fare 
components a set of fares that are valid for and 
associated with the itinerary sets. 

According to a further aspect of the invention a 

10 method for determining a set of fares for a set of 

itineraries includes retrieving itinerary sets for at 
least one slice of a journey, parsing retrieved 
itinerary sets into faring atoms that correspond to one 
or more travel unit segments spanned by a single fare 

15 and applying rules to the faring atoms to produce fare 
components. The method also includes constructing from 
the fare components a set of fares that are valid for 
and associated with the itinerary sets. 

According to a further aspect of the invention, a 

20 method for determining pricing solutions includes 

retrieving itinerary sets for all slices of a -journey 
and decomposing said itinerary sets into faring atoms. 
The method also includes applying rules to said faring 
atoms to produce valid faring atoms that are grouped 

25 into faring components, constructing priceable unit data 
structures from the faring components and linking 
itineraries and priceable units into a data structure 
that represents pricing solutions. 

According to a still further aspect of the 

30 invention, a computer system for determining pricing 
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solutions includes a computer and a computer readable 
medium storing a computer program. The computer program 
has instructions that causes the computer to retrieve 
itinerary sets for all slices of a journey, decompose 

5 said itinerary sets into faring atoms, apply rules to 
the faring atoms to produce valid faring atoms that are 
grouped into faring components, construct priceable unit 
data structures from the faring components, and link 
itineraries and priceable units into a data structure 

10 that represents pricing solutions. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing features and other aspects of the 
invention will be: described in further detail by the 
15 accompanying drawings, in which: 

FIG. 1 is a block diagram of a client server travel 
planning system. 

FIG. 2 is a flow chart showing a server process 
used in the system of FIG. 1. 
20 FIG. 3 is a flow chart showing a client process 

used in the system of FIG. 1. 

FIGS. 3A-3B are diagrammatic representations of 
pricing graphs. 

FIGS. 4A-4B are flow charts showing a faring 
25 process used in the server process of FIG. 2. 

FIG. 5 is a flow chart showing a process to 
decompose an itinerary into faring atoms used in the 
process of FIG. 4A. 
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FIG. 6 is a flow chart showing a process for 
partitioning itineraries used in the process of FIG. 5. 

FIG. 7 is a flow chart showing a process for 
applying rules to faring atoms used in the faring 
5 process of FIG. 4A. 

FIGS. 8A-8C are flow charts showing a process for 
retrieving fare rules. 

FIG. 9 is a flow chart showing a process for 
applying fare rules . 

10 

FIG. 10 is a flow chart showing a process for 
determining priceable units used in the faring process 
of FIGS . 4A-4B. 

FIG. 10A is a flow chart showing a process for 
15 enumerating collections of sets of faring components 
used in the process of FIG. 10. 

FIG. 11 ,is a flow chart showing a process for 
enumerating collections of faring components used in the 
process of FIG. 10. 

20 FIG. 12 is a flow chart showing a process for 

representing priceable units in a compact 
representation. 

FIGS. 13-15 are flow charts showing processes for 
determining priceable units. 

25 FIG. 16 is a flow chart showing a process for 

producing slice label sets . 

FIG. 17 is a flow chart showing the process for 
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constructing a pricing graph. 

FIG. 18 is a block diagram showing the relationship 
between the pricing graph and a graphical user interface 
for the travel planning system of FIG. 1. 

5 FIG. 19* is a flow chart showing various enumeration 

functions. 

FIG. 20; is a diagram of a window depicting a user 
interface. 

FIG. 21 is a diagram of a window used in an initial 
10 query; 

FIG. 22 is a diagram of a window depicting an 
exemplary solution of a one-way travel request. 

FIG. 23 is a diagram of a window depicting an 
itinerary and associated fares corresponding to one of 
15 the solutions depicted in FIG. 21. 

FIG. 24 is a diagram of a window depicting an 
exemplary solution of round trip travel request. 

FIG. 25 is a diagram of a window depicting an 
outbound itinerary and a possible return itinerary and 
20 associated fares corresponding to one of the solutions 
depicted in FIG. 24. 

FIG. 26 shows the window generally depicted in 
conjunction with FIG. 24 modified based upon a user 
selected criteria. 
25 FIG. 27 shows a window depicting a histogram. 



DETAILED DESCRIPTION 
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Referring now to FIG. 1, a travel planning system 
10 is shown. The travel planning system can be used 
with various forms of travel such as airline, bus and 
railroad and is particularly adapted for air travel. It 
5 includes a server computer 12 having a computer memory 
or storage media 14 storing a server process 15. The 
server process includes a scheduler process 16 and a 
faring process 18. The scheduler process 16 is any 
suitable scheduler process that will produce from a 

10 travel request sets of flights that can satisfy the 
request. The faring process 18 is a process that 
determines a set of valid fares and links the set of 
valid fares to the sets of flights to form a pricing 
solution. The server process 15 can be configured to 

15 produce other travel -related information as a result of 
a user query. For example, the server process 12 can 
produce routes or airline suggestions, optimal travel 
times and suggestions for alternative requests. 

The travel planning system 10 also includes a 
20 plurality of databases 20a, 20b which store industry- 
standard information pertaining to travel (e.g., 
airline, bus, railroad, etc. ) . For example, database 
20a can store the Airline Tariff Publishing Company 
database of published airline fares and their associated 
25 rules, routings and other provisions, the so-called 
ATPCO database. Database 2 0b can be an. inventory of 
current availability of airline information for a 
particular carrier and so forth. The databases 20a-20b 
are typically stored locally and updated periodically by 
30 accessing remote resources 21a, 21b that maintain the 
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respect i ve databases . 

T he system 10 also includes a plurality of clients 
30a-30c implemented by terminals or preferably personal 
computers. The clients 3 0a- 3 0c are coupled to the 
5 server 12. via a network 22 which is also used to couple 
the remote resources (21a-21c) that supply the databases 
20a-20b to the server 12. The network 22 can be any 
local or wide area network or an arrangement such as the 
Internet . 

10 The clients 30a-30c are preferably smart clients. 

That is, using client 3 0c as an illustrative example, 
client 30c includes a client computer system 32 
including a computer memory or storage media 34 that 
stores a client process 36 and- a set of pricing. 
5 solutions 38. The set of pricing solutions 3 8 in one 
embodiment is provided from the server process 16 and 
comprises a set of fares that are valid for a journey, 
and associated information linking the fares to the 
flight segments of the journey. 

20 The set of pricing solutions 38 is obtained from 

* the server 12 in response to a user request sent from 
the -client 30c to the server 12. The server 12 executes 
the server process 15 using the scheduling process 16 
and the faring process 18 to produce a set of pricing 

25 solutions for a particular journey. If requested by the 
client, for example client 3 0c, the server 12 will 
deliver the set of pricing solutions 3 8 to the 
requesting client 30c. Under control of the client 
process 36, the requesting client 30c can store and/or 
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logically manipulate the set of pricing solutions 38 to 
extract or display a subset of the set of pricing 
solutions as a display representation 41 on the monitor 
40 . 



SERVER PROCESS 

Referring now to FIG. 2, the server process 18 is ■ 
preferably executed on the server computer 12 but could 
be executed on the client computer 32. The server 
10 process 18 is responsive to a user input query 48. The 
user input query 4 8 would typically include minimal 
information needed to determine a set of pricing 
solutions. This information typically requires at a 
minimum, an origin and a destination for travel . In 
15 addition, the information could also include times, 
dates and so forth. 

This query 4 8 is fed to the scheduler process 16 
that produces a large number of itineraries, that is, 
sequences of flight segments between the origin and 
20 destination for each slice of a journey. Examples of 
scheduler systems that may be used include the OAG 
Flight Desk (Official Airlines Guide, a division of Reed 
Travel Group) or schedule components of computer 
reservation systems (CRS's) such as Sabre®, Apollo®, 
25 Amadeus® and WorldSpan®. It is preferable in order to 

obtain the largest number of possible itineraries to use 
a scheduler with dynamic connection generation. Such a 
scheduler is described in co-pending patent application 
entitled srHRnm.ER p vstfm for TRAVEL PLANNING SYSTEM , 
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Serial No. , filed on by Carl Q- 

dpMarckfin et al . and assigned to the assignee of the 
invention and incorporated herein by reference. 

The scheduler process 16 provides the itineraries 
5 to a faring-,process IB. The faring process 18 provides 
a set of pricing solutions 3 8 by finding valid fares 
corresponding to the itineraries produced by the 
scheduler process 16. The faring process 18 validates 
the fares for inclusion in the set of pricing solutions 
10 38 . 

The set of pricing solutions 3 8 is used by an 
availability system 58 that interrogates an airline 
inventory database 20b to determine whether there are 
seats available on particular flights for particular 
15 pricing solutions. The availability system 58 uses the 
airline inventory database 2 0b as a filter to remove 
from the set of pricing solutions 38 those pricing 
solutions for which there are not available seats. The 
availability system 58 is shown after the faring process 
20 18. However, it could be included at nearly any point 
-in the server process 18. In addition, it is shown 
being fed by the pricing solution when it may only 
receive flight information from the scheduler process 16 
depending on the airline. 
25 The client system 3 0c receives the results from the 

server process 18. These results are the set of pricing 
solutions 3 8 and/or pricing solutions based upon 
availability. The client process 3 6 executed in the 
client 30c uses this information or a subset of it to 
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access a booking system 62 to provide a booking and 
reservation for a user selected, enumerated pricing 
solution, as will be described below. 

5 CLIENT PROCESS 

Referring now to FIG. 3, the client process 3 6 
receives a listing of possible itineraries from the 
scheduler process 16 as well as the set of fares from 
the faring process 18 or the availability system 58. 

10 The set of pricing solutions 38, if obtained from the 
faring process 18, will include a large number of 
pricing solutions for which there is not any available 
inventory. Therefore, the components would need to be 
first checked out with an airline prior to booking. : The 

15 set of pricing solutions 38 if obtained after the 

availability system 58 should contain pricing solutions 
which have a high degree of availability for booking on 
an airline. 

In one embodiment , the set of pricing solutions 3 8 
20 is provided in a compact representation 38 1 . A 

preferred, compact representation 38* of the set of 
pricing solutions 38 is as a data structure comprising a 
plurality of nodes including itineraries and fares and 
that can be logically manipulated using value functions 
25 to enumerate a set of pricing solutions. One preferred 
example is a graph data structure type particularly a 
directed acyclic graph (DAG) that contains nodes that 
can be logically manipulated or combined to extract a 
plurality of pricing solutions. 
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The client process 3 6 receives the flight 
information from scheduler, process 16 and the pricing 
solution from the faring process 18 or the availability 
system 56 and enumerates pricing solutions from the 
5 directed acyclic graph (DAG) representation. The 

enumerated set of pricing solutions is rendered in a 
graphical user interface 41 on. the client monitor 40 
(FIG. 1) in a manner as will be described below. 

In response to user input 76, the client 4 0 can 
10 manipulate travel options and can query the local copy 
of the DAG to produce and display a subset of pricing 
solutions enumerated from the DAG that satisfy the query 
76. The manipulation process used to control the 
display and change the travel options will be described 
15 below. 

A directed acyclic graph (DAG) is used to represent 
the compact set of pricing solutions 38 1 since, in 
general, the number of nodes needed to represent a 
typical pricing solution will be substantially less than 
20 the actual number of pricing solutions represented by 

-the DAG. This significantly increases the efficiency of 
transfer of a set of pricing solutions 3 8 from the 
server process 18 to the client process 36. The DAG 
representation also minimizes the storage requirements 
25 for the set of pricing solutions 38. The DAG 

representation permits the use of powerful search, 
sorting and manipulation processes to produce various 
subsets of set of pricing solutions in an efficient 
manner. As used herein, a directed acyclic graph (DAG) 
30 is a set of nodes connected by directed arcs, that have 
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no loops of arcs in the same direction. If a node A is 
connected to a node B via an arc A-*B, then A is called a 
parent of B, and B is called a child of A. Each node 
may have zero, one or many parents and zero, one or many 
5 children. ^s used herein, a pricing solution that is 
represented by a graph will be referred to as a pricing 
graph . 

PRICING -GRAPH 

10 A pricing graph that is produced by the faring 

process 18 and that represents a pricing solution 
includes three types of nodes. The first type of node 
is an exclusive node, i.e., M OR n node. An OR node N with 
children A, B and C represents an exclusive choice 

15 between A, B and C. In other words, a pricing-solution 
involving node N contains either the fares and 
itineraries represented by A, or by B, or by C. 

The second type of node is a collection node, i.e., 
an "AND" node. An AND node N with children A, B and C 
20 represents the sum of A, B and C. In other words, a 

pricing solution involving N contains all the fares and 
itineraries found within A, B and C. 

The third type of node is a terminal node. 
Terminal nodes are used to hold pricing objects. 
25 Pricing objects include fares, itineraries, surcharges, 
routes, prices, booking codes, taxes, rules/restrictions 
and other information of the user or information that 
might be part of a travel option. 
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Collectively, "AND" and "OR" nodes are non- terminal nodes. 

An example of the pricing-graph for a hypothetical 
round-trip journey is presented below in TABLE 1. For 
each node, its type and children are listed. If a node 
5 is a terminal , the fare or itinerary is provided. Many 
nodes in the pricing graph have more than one parent. 

TABLE 1 



Node 


Type 


Children 


Object | 


0 


OR 


Nodes 1, 2, 3 




1 


AND 


Nodes 10, 14, 17, 17 




2 


AND 


Nodes 4 . 5 




3 


AND 


Nodes 13, ^ 15, 19, 19 




4 


OR 


Nodes 8, 9 


- — v— 


5 


OR 


Nodes 6, 7 




6 


AND 


Nodes 14, 16 




7 


AND 


Nodes 15, 18 




8 


AND 


Nodes 13, 16 




9 


AND 


Nodes 13, 18 




10 


OR 


Nodes 11, 12 




XI 


Itin. 




Slice 1: BOS-LAX UA023 


12 


Itin. 




Slice 1: BOS-DFW UA100, 
DFW-LAX UA103 


13 


Itin. 




Slice 1: BOS-SAN NW222 


14 


Itin. 




Slice 2: LAX-BOS UA515 


15 


Itin. 




Slice 2: SAN-BOS NW223 


16 


Fare 




UA BOS -LAX One-way tt Y" 


17 


Fare 




UA BOS -LAX Round- trip "QE7NR" 


18 


Fare 




NW BOS -SAN One-way **F H 


19 


Fare 




NW BOS -SAN Round- trip "H7NR" 



This pricing -graph represents a total of nine 
10 pricing solutions. These solutions can be extracted 

from the pricing-graph by descending from the root node, 
node 0. At every OR node a choice between children is 
made, and the choice determines the pricing-solution 
that results. At every AND node each child branch is 
15 descended, and the results are combined. 

The term BOS-LAX UA023 is an itinerary which uses 
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standard nomenclature to represent airports BOS and LAX, 
airline UA, and flight number .023. In general, 
conventional nomenclature used in the airline industry- 
will be used herein. 

The set of pricing-solutions that represented in 
the pricing-graph is presented in TABLE 2 below. 

TABLE 2 



Solution 
Number 


Itineraries 


Fares 


1 


Slice 1: BOS-LAX UA023 
Slice 2: LAX-BOS UA515 


UA BOS -LAX RT "QE7NR" 
UA BOS -LAX RT "QE7NR" 


2 


Slice 1: BOS-LAX UA023 
Slice 2: LAX-BOS UA515 


UA BOS -LAX OW "Y* 
UA BOS -LAX OW - Y" 


3 


Slice 1: BOS-LAX UA023 
Slice 2: SAN-BOS NW223 


UA BOS -LAX OW tt Y" 
NW BOS t SAN OW **F" 


4 


Slice 1: BOS-DFW UA100 , 
DFW_LAX UA103 

Slice 2: LAX-BOS UAS1S 


UA BOS -LAX RT "QE7NR" 
UA BOS -LAX RT "QE7NR" 


5 


Slice 1: BOS-DFW UA100, 
DFW_LAX UA103 

Slice 2: LAX-BOS UA515 


UA BOS -LAX OW "Y" 
UA BOS -LAX OW "Y* 


6 


Slice. 1: BOS-DFW UA100, 
DFW_LAX UA103 

Slice 2: SAN-BOS NW223 


UA BOS -LAX OW U Y" 
NW BOS -SAN OW "F - 


7 


Slice 1: BOS-SAN NW222 
Slice 2: LAX-BOS UA515 


NW BOS -SAN OW "F" ^ 
.UA BOS-LAX OW "Y" 


8 


Slice 1: BOS-SAN NW222 
Slice 2: SAN-BOS NW223 


NW BOS -SAN RT "H7NR" 
NW BOS -SAN RT "H7NR" 


9 


Slice 1: BOS-SAN NW222 
Slice 2: SAN-BOS NW223 


NW BOS -SAN OW "F" 
NW BOS -SAN OW "F" 



The pricing-graph encodes the requirement that two 
itineraries are combined, one from slice 1 and one from 
slice 2, to form a pricing solution. Further, each 
itinerary is spanned by fares. In this case each 
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pricing solution involves two fares, and round- trip 
fares are combined with like round-trip fares. In most 
circumstances, the number of nodes in the pricing-graph 
is small compared to the number of pricing-solutions 
5 those nodes., represent . In many cases, a graph of 10,000 
or so nodes can represent more than 1,000,000,000 
pricing-solutions . - 

Referring now to FIG. 3A, the nodes of the pricing 
graph corresponding to Table 1 are shown, as an example. 

10 This figure illustrates the manner in which nodes in 

the pricing graph data structure as represented in Table 
1 are combined to provide the pricing solutions shown in 
Table 2. Using pricing solution No. 1 (from TABLE 2) as 
an example, it can be shown that starting at. the top of 

15 the graph at node 0, node 0 allows for a choice between 
nodes 1, 2, and 3. For pricing solution No. 1, Node 1 
is chosen. Node 1 is the AND node that points to nodes 
10 and 14, and has two pointers to node 17. Node 10 is 
an OR node which provides a choice of either nodes 11 or 

20 nodes 12. Node 11 as shown in FIG. 3A corresponds to a 
_ terminal node, the itinerary ('BOS-LAX UA 023). Node 12 
corresponds to a terminal node, the itinerary BOS-DFN UA 
100, DFN-LAX UA 103. This second choice in node 10 will 
provide pricing solutions corresponding to numbers 4-6, 

25 respectively. Therefore, selecting node 11 provides the 
itinerary for the first slice of solution 1. The fare 
for pricing solution 1 is provided by node 17 which has 
two pointers, one for each slice, to the fare "US BOS -LAX 
RT QE7NR" corresponding to the fare shown for pricing 

30 solution no. 1 in Table 2 for the first slice. The 
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second itinerary for pricing solution no. 1 is provided 
by node 14 which is referenced in AND node 1 that points 
to the itinerary LAX-BOS UA 515. The corresponding fare 
is also from terminal node 17 since it is a round trip 
5 fare UA BOS^LAX RT QE7NR. 

A second one of the pricing solutions, for example, 
the pricing solution 4 incorporating the terminal node 
12 is provided by starting at node 0, and using node 1. 
Node 1 is an AND node requiring that nodes 17 (twice) , 

10 node 10, and node 14 be included. Node 10 is an OR node 
as mentioned above and is used to select node 12 which 
is the itinerary including segments "BOS-DFW UA 100" and 
"DFW-LAX UA 103". From node 1, node 14 the return 
itinerary LAX -BOS UA 515 also is reached.- Node 17 also. 

15 is chosen which contain the round trip fares. 

Similarly, the remaining ones of the pricing solutions 
can be extracted from the pricing graph in the same 
manner as the two examples given above. 

As mentioned above, a graph will typically have 
20 many more pricing solutions than nodes in the-graph. 

"The example just illustrated in conjunction with FIG. 3A 
has 9 pricing solutions and 19 nodes which is an 
exception to that general rule. Another example of a 
pricing graph which does satisfy that general 
25 observation is shown in conjunction with FIG. 3B. 

- Referring now to FIG. 3B, a pricing graph is shown 
having 43 nodes N0-N42 that when combined represent 856 
pricing solutions. Each node in the pricing graph has a 
number associated with it corresponding to the number of 
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pricing solutions that is represents. In order to make 
this illustration of manageable size, identifiers 
(representing the nodes of the terminals) are 
substituted in the pricing graph for the actual terminal 

5 objects of the graph. Thus, as shown in FIG. 3B, 
outbound and return itineraries, and fare nodes are 
represented by the -Nodes N2 0-N42 This pricing graph 
(TABLE 3) has 9 itineraries which can be combined with 
14 fares represented by 13 AND nodes and 7 OR nodes. 

10 The pricing objects are represented by 23 nodes. The 
pricing graph has a combined total of 43 nodes to 
represent 876 pricing solutions. 

FIG. 3B shows examples of a pricing graph for a 
round trip LAX -BOS. journey. This example shown in FIG. 
15 3B is generally more representative of an outcome of a 
faring search. That is, generally the pricing graph 
represents more pricing solutions than nodes contained 
in the graph. 

TABLE 3 



Node 


Type 


Children 


Object | 


0 


AND 


Nodes 1, 6, 11 




I 


OR 


Nodes 2, 3, 4 




2 


AND 


Nodes 5, 40 




3 


AND 


Nodes 41, 41 




4 


AND 


Nodes 42, 42 




5 


OR 


Nodes 39, 40 




6 


OR 


Nodes 7 ,8, 9 




7 


AND 


Nodes 20, 10 




8 


AND 


Nodes 21, 10 




9 


AND 


Nodes 22, 10 




10 


OR 


Nodes 23, 24, 25, 26 




11 


OR 


Nodes 12, 13, 14, 
16, 17, 18 




12 


AND 


Nodes 27, 15 




13 


AND 


Nodes 28, 15 




14 


AND 


Nodes 29, 15 
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15 


AND 


Nodes 30, 31, 32 




16 


AND 


Nodes 33, 19 




17 


AND 


Nodes 34, 19 




18 


AND 


Nodes 35, 19 




19 


OR 


Nodes 36, 37, 38 




20 


Itin. 




Slice 1: LAX-DFW NW100, 
DFW- BOS AA223 


21 


I tin- * 




Slice 1: LAX-DFW NW137, 
DFW-BOS AA223 


22 


Itin. 




Slice 1: LAX-DFW NW13 7, 
DFW-BOS AA414 


23 


Fare 




DFW, LAX NW "Y" OW 


24 


Fare 




DFW, LAX NW "F* OW 


25 


Fare 




DFW, LAX NW -C" OW 


26 


Fare 




DFW, LAX NW **QA7 " OW 


27 


Itin. 




Slice 2: BOS-DFW AA67, 
DFW- LAX C0716 


28 


Itin. 




Slice 2: BOS-DFW . AA6 7, 
DFW— LAX C0717 


29 


Itin. 




Slice 2: ;. BOS- DFW AA67, 
DFW— LAX C0719 


30 


Fare 


r 


DFW, LAX CO *F" OW 


31 


Fare 




DFW, LAX CO "C* OW 


32 


Fare 




DFW, LAX CO "Y" OW 


33 


Itin. 




Slice 2: BOS-DFW AA852, 
DFW— LAX DL186 


34 


Itin. 




Slice 2 * BOS-*DFW AAA 1 ?? 
DFW— LAX DL180 


35 


Itin. 




Slice 2: BOS-DFW AA852 , 
DFW— LAX DL343 


36 


Fare 




DFW, LAX DL m F m OW 


37 


Fare 




DFW, LAX DL U C* OW 


38 


Fare 




DFW, LAX DL M Y" OW 


39 


Fare 




DFW, BOS AA **QE7NR" RT 


40 


Fare 




DFW, BOS AA "QE7IP" RT 


41 


Fare 




DFW, BOS AA "QE14NR* RT 


42 


Fare 




DFW, BOS AA "QE21NR* RT 



THE FARING SYSTEM 

Referring now to FIGS. 4A and 4B, the faring 
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process 18 includes a process 80 to retrieve itinerary 
sets for all slices in an itinerary. The itinerary sets 
are provided from the scheduler process 16 for each 
slice of a journey where a slice corresponds to a 

5 direction of travel. Thus, for example, for a round 
trip journey there would be two slices, one for the 
outbound part of the journey and one for the return part 
of the journey. The faring process 18 decomposes 82 the 
itinerary into faring atoms. As used herein, faring 

10 atoms refer to a sequence of flight segments or 

equivalently legs that are spanned by a single fare. 
For example, the itinerary 

UA005 from DFW to BOS at 12:30 on 12NOV 

UA010 from BOS to YYZ at 18:00 on 12NOV 

15 AC121 from YYZ to YVR at 01:00 on 13NOV 

permits the following faring-atoms as shown in TABLE 4. 



TABLE 4 



Faring-Atom Number 


Legs and Deparcure Times 


1 


DFW-BOS UA005 12NOV 12:30 


2 


BOS-YYZ UA010 12NOV 18:00 


3 


DFW- BOS UA005 12NOV 12:30 
BOS-YYZ UA010 12NOV 18:00 


4 


YYZ-YVR AC121 13NOV 01:00 



20 A faring atom is represented by a data structure 

that preferably includes the following fields as shown 
in TABLE 5: 



WO 00/02152 



PCT/US99/1496I 





21 




TABLE 5 


Faring-Atom fields 


Use 


legs -and- departure- times 


A list of legs and their departure times 
and dates. 


faring- market 


The faring -market that this faring-atom is 
in. 


cached- results 


A storage space used to eliminate 
redundant computation in the rule- checking 
process. As rule record-2s are applied to 
f aring-atoms, the results are stored in 
this field. If the same record-2 is 
applied again, the answer is retrieved 
rather than recomputed. 


priceable- unit -labels 


A list of the priceable -unit- labels that 
the faring-atom enters into. 



After the faring process 18 decomposes the 
itineraries into faring atoms, the faring process 18 
5 retrieves fares 84 and rules 86 for each faring atom by 
accessing the fares/rules database 20a mentioned above. 

At this point a fare's routing is retrieved from a 
routing database and applied to a faring atom. If the 
routing test fails, the fare cannot be applied to the 
10 faring atom and a fare component is not built . 

The faring process 18 applies the rules 8 8 to the 
faring atoms to produce fare components. Fare- 
components are combinations of f aring-atoms and fares. 
Fare -components (TABLE 6) are produced if a fare's rules 
15 pass a preliminary check, on a faring-atom. They are 
used to store deferred rules (e.g., deferred record-2s 
and combinability record-2s) that are applied at a later 
stage of processing. Fare components also store extra 
information produced during the rule -checking process, 
20 such as information about surcharges and penalties and 
discounts that are applied to the base fare price. 

TABLE 6 
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Fa re -Component fields 


Use 


fare 


The fare -component's fare. 


f aring-atom 


The fare -component's f aring-atom. 


deferred- record- 2s 


A list of non-category-10 record-2s 
that have not been fully evaluated. 


combinability-record-2 


If the fare's rules include a category- 
10 ("Fare Combi liability" record-2, it is 
stored here . 


surcharges 


A list of surcharges, penalties, 
discounts and other pieces of 
information produced during the rule- 
checking process. 



From the fare components the faring process 18 
constructs 90 priceable units. For certain types of 

5 rules such as those which require access to fares and/or 
flights from outside of the fare component, those rules 
are stored in the fare component for later or deferred 
evaluation. The priceable unit process 90, takes vaiid 
fare components and constructs priceable units from the 
10 fare components. This process 90 involves grouping fare 
components from different slices and checking fare 
component combination restrictions. At this stage of 
processing, the rules deferred in step 88 are reapplied. 
Priceable units are represented by priceable-unit - 

15 "cores and priceable-unit-labels. Priceable-unit -cores 
are collections of fares and other information 
associated with fares within a priceable-unit, such as 
discounts and penalties and surcharges. Priceable-unit - 
cores (TABLE 7) are referenced by priceable-unit-labels. 

20 

TABLE 7 



Priceable-Unit-Core. fields 


Use 






fares 


A list 


of 


fares . 


slice- numbers 


A list 


of 


the slices the fares 
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originace from. 


surcharges 


A list of surcharges, penalties, 
discounts and other pieces of 
information produced during the rule- 
checking process . 



Priceable-unit-labels group a set of priceable-unit- 
cores with sets of. f aring- atoms . Together, they are 
used to represent sets of priceable-units (TABLE 8) . 

5 

TABLE 8 



Priceable -Unit -Label 


Use 


fields 




priceable-unit-cores 


A set of priceable-unit cores. 


slice- numbers 


A list of the slices the fares and 
faring-atoms originate from. 


faring -a torn- sets 


A list of sets of faring-atoms, one 
per slice. 



When all the fare components within a priceable unit are 
known, rules that were deferred from the processing 8 8 
10 are applied 92 to the priceable unit sets of faring 
atoms . 

After evaluation of the deferred record-2s at the 
priceable unit stage, the itineraries; and priceable 
units are grouped together into complete set of pricing 

15 solutions. This occurs by a link process 94 that links 
itineraries to corresponding pricing units from 
different slices to provide the pricing solution. At 
this juncture, any remaining cross priceable unit fare 
combinability checks are performed to eliminate invalid 

20 combinat ions . 

The linking process involves two additional data 
structures slice-label-sets and open-label-sets. Slice- 
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label -sets group itinerary divisions by the multi-slice 
priceable -unit -labels they can enter into. In each 
slice of a journey, a unique slice-label-set is 
constructed for every set of multi-slice priceable-unit- 
5 labels. Each slice-label-set stores both the set of 
multi-slice priceable-unit-labels and a set of 
itinerary -label -holders, which contain single- slice 
priceable-unit-labels on a per-itinerary basis. Each 
slice-label-set is a pair of an itinerary and a set of 
10 division- label -holders. Each of these division-label- 
holders is a pair of a division and a set of sets of 
single-slice priceable-unit-labels (TABLE 9) . 



TABLE 9 



Slice-Label-Set fields 


Use 






multi-slice-PU- labels 


A set 


of 


multi-slice PU- labels. 


itinerary- label -holders 


A set 


of 


itinerary- label -holders . 



15 



Itinerary- Label-Holder, fields 


Use j 


itinerary 


An itinerary. 


division- label-holders 


A set of division-label -holders . 




Division-Label-Holder fields 


Use 


division 


An itinerary division. 


single-slice- PU- label -sets 


A set of sets of single-slice PU- 
labels . 



Open- label -sets (TABLE 10) are used to summarize the 
state of the linking process 94. Each is a set of "open" 
multi-slice priceable-unit-labels and a set of backward- 
20 links. Each of these backward- links is a pair of a 
slice-label-set and an open- label -set . 
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TABLE 10 



Open-Label-Set fields 


Use 


open- PU- labels 


A set of open multi-slice PU-labels. 


backward - 1 inks 


A set of backward- links . 




Backward- Link fields 


Use 


slice- label -set 


A slice- label- set . 


open- label - set 


An open-label-set. 



The pricing solution resulting from the linking 
5 process 94 is used to construct a pricing graph from the 
various data structures built during the preceding 
processes. This pricing graph is transmitted to the 
client process or can be stored for later use or 
transmission. A pseudocode representation of the high 
10 level processing logic involved in the above search . 
procedure is set out below in TABLE 11. 
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TABLE 11 



price-itinerary-sets(itinerary-sets, fare-database, rule-database, routing-database, environmental-information) 
// 

// itinerary-sets is a set of sets of itineraries, one per slice. 

// environmental-information contains information about the passenger, the current date, the location 

// where tickets will be purchased, and other non-itinerary-based information that is necessary for applying 

// fare rules, 

// 

Let faring-market-sets = Q 

// Construct itinerary-divisions, faring-markets and faring-atoms. 
Let slice-number = 1 
For itinerary-set in itinerary-sets 
// 

// create-divisions constructs the itinerary-divisions, faring-markets and faring-atoms for 
// all the itineraries within a slice. It returns a set of faring-markets. 
faring-market-sets += create-divisions<itineraries, slice-number, fare-database) 
slice-number += 1 

// Apply fare rules, constructing fare-components in each faring-market 
For faring-market-set in faring-market-sets 
// 

// apply-fare-ruies constructs fare-components for each faring-market within a slice. 
// This process contains pseudo-code for appty-f are-rules. 
apply-fare-rules<faring-market-set, fare-database, rule-database. 

routing-database, environmental-information) 

// Create priceable-units. 

//for create-priceable-units 

create-priceable-units(faring-market-sets) 

// Link itineraries between slices. This procedure returns either nil, if there are no pricing-solutions, or 
// a "root" open-label-set This process is described in link-itineraries 
Let root-object = link-itineraries(itinerary-sets) 
if (root-object = nil) 
retum(nil) 

// Create the pricing-graph from the data-structures that have been built in the preceding steps. 
// This process includes psedo-code for create-pricing-graph. 
Let root-node = create-pricing-graph(root-object) 

// Return the pricing graph. 
retum(root-node) 



5 Referring now to FIG. 5, the process 82 to 

decompose an itinerary into faring atoms includes a 
retrieval process 100 that retrieves all itineraries for 
all slices in a journey. For each itinerary in each 
slice, the process 82 groups faring atoms by faring 

10 markets at 104 and partitions itineraries into the 
divisions of faring atoms at 106. 
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Referring now to FIG. 6, itineraries are 
partitioned into divisions of faring atoms by examining 
110 for each itinerary whether or not the itinerary 
includes more than one leg 112 on the same airline 114. 
5 For each sequence on the same airline, a faring-atom is 
produced. If the sequence has more than one leg, the 
sequence is also split into multiple faring-atoms (at 
116) , resulting in more than one division of the 
itinerary into a set of faring-atoms. The process 

10 checks 118 whether fares exist for the airline in the 
markets spanned by each faring atom. Otherwise, the 
process will branch from the examination process 112 and 
the airline check process 114 to a fare check process 
118 to check in the fare database 20a that a fare exists 

15 for the airline in the market spanned by the faring 1 

atom. If all of the faring atoms within a division have 
at least one fare in the market, a division for the 
market is produced at 120. Another possible 
implementation creates divisions by producing all 

20 possible partitions of legs into faring-atoms. 

A high-level pseudocode representation for the 
algorithm that generates faring atoms, faring markets 
and faring divisions for each itinerary within a slice 
is set forth below in TABLE 12. 
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TABLE 12 



create-divtsions(itineraries, slice-number, fare-database) 

Let faring-atoms = 0 
Let faring-markets = 0 

Subroutine get-farino>market(origin-airpOft, destination-airport, airline) 
Let origirvnpity = dty(origin-airport) 
Let destination-city = city(destination-airport) 

Let previous-faring-market = find<<origin-city, destination-city. airUne>, faring-markets) 
If (previous-faring-market) 

retum(previous-faring-market) 

Else 

If (fares-exist(origin-city, destination-city, airline)) 
Let faring-market = new-faring-market() 
faring-marketslice-number » slice-number 
faring-marketorigiin-city = origin-city 
faring-marketdestination-city = destination-city 
faring-marketairiine = airline 
taring-marketfaring-atoms = 0 
faring-markets += faring-market 
retum(faring-market) 

Else 

retum(nil) 

Subroutine get-faring-atom(legs-and-departure-times, origin-airport, destination-airport, airline) 
Let previous-faring-atom = find(legs-and-departure-times. faring-atoms) 
If (previous-faring-atom) 

retum(previous-faring-atom) 

• Else 

Let faring-market = get-faring-market(origin-airport destination-airport, airline) 
If (faring-market o nil) 

Let faring-atom = new-faring-atom() 

faring-atom.faring-market = faring-market 

faring-atom.legs-and-departu re-times = tegs-and-departure-times 

faring-atom.priceable-unit-labels = 0 

faring-atom. cached -results = 0 

faring-marketfaring-atoms += new-faring-atom 

faring-atoms faring-atom 

retum<faring-atom) 

Else 

retum(nil) 

Subroutine get-online-divisions(legs-and-<Jeparture-times, origin-airport destination-airport, airline) 
Let online-divisions = 0 

Let number-of-legs = length(legs-and-departure-times) 

Let single-faring-atom = get-faring-atom(legs-and-departure-times. origin-airport, destination-airport, airline) 
If (single-faring-atom <> nil) 

online-divisions += list(single-faring-atom) 
For t from 1 to number-of-legs - 1 

Let legs-and-departure-timest = legs-and-departure-times(1...i) 

Let Iegs-and-departure-times2 = legs-and-departure-times[i+1... number-of-legs) 

Let destinaUon-airportl = destinatiorvairport(faring-atom-tegs1) 

Let origin-airport2 = origin-airport(faring-atorn-legs2) 

If (is-not-same-flight-segment(legs-and-departure-times1 , Iegs-and-departure-times2)) 
Let faring-atoml = get-faring-atom(legs-and-departure-tirnes1 , origin-airport, 

destination-airportl , airline) 
Let faring-atom2 = get-faring-atom(legs-and-departure-times2. origin-airport2, 

destination-airport, airline) 
If (faring-atoml <> nil and faring-atom2 <> nil) 

online-divisions list(faring-atom1 , faring-atom2) 
retum(online-divisions) 

For each itin rary in itineraries 
Let divisions = { 0 ) 

Let tegs-and-departure-times = itinerary.legs-and-departure-times 
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Referring now to FIG. 7, a process 88 to apply the 
faring rules to faring atoms is shown. The input to the 
5 application 'process 88 includes the fare/rules database 
20a and faring markets 130. For each faring atom in 
each faring market, a fare and corresponding rules are 
retrieved 132 from fare/rules database 2 0a. The rules 
are applied to the f aring-atoms at 134 . Because f aring- 

10 atoms are shared across itineraries, it is only 

necessary to apply a fare's rules to a faring atom once 
no matter how many itineraries the faring -atom may 
appear in. The results of rule applications are cached 
136. , Caching of a rule minimizes computational effort. 

15 This is because the rule application process 88 

involves many redundancies, because different fares 
share rule restrictions. Valid fare/ faring- atom 
combinations are stored 138 in the form of fare- 
components . 

20 Referring to FIGS. 8A and 8B, a process 132 for 

"retrieving rules and footnotes from the rules database 
2 0a containing the ATPCO rules, routes and fares 
includes retrieving 150 general rules commonly referred 
to as record_0 1 s for each faring atom in a faring 

25 market. The retrieved general rules are searched 152 to 
find the first record^ 0 matched to the faring atom to 
produce a matched record_0 . If there is a matched 
record^ 0, it is stored at 154. whether or not there are 
matched record_0's, the process 132 retrieves 156 
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application rules commonly referred to as record_l 
rules. The retrieved application rules are searched to 
find the first record^ 1 matched to each of the faring 
atoms. The first matched record_l ' s is stored 160. 

5 If after traversing through all the record_l ' s 

there are no matches found, the process will return a 
"FAIL" at 162 and terminate indicating that the faring 
atom cannot be used by the faring process 18. 

If there is a match, the process 132 retrieves 164 
10 category controls (commonly referred to as record_2's). 
The process 132 will find the first record-2 in each 
category that matches the fare. Record_2 • s or the 
category control records typically comprise a large 
number of categories currently 30 different categories. 
15 The process is run for each category. It is not 

necessary that every category have a match and in many 
instances many if not most categories will not have a 
match. Rules in those categories that have a match are 
stored at 168 and the process continues to run at 170 
20 until all categories have been traversed. If. all 

'categories have not been traversed, a pointer to a next 
category 172. is set and the next category is retrieved 
164. Record-3 f s are retrieved as part of the rule 
application process 132. 

25 The ATPCO rule retrieval process 132 that retrieves 

the rules for a fare includes record-matching processes 
150, 156, and 164 (FIG. 8A) that may depend on the 
departure date of the faring-atom. To minimize 
computational effort expended in rule retrieval 132, 
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rules for a fare are not retrieved once for 
every faring-atom, but at most once per departure-date. 
To further minimize computation, a caching mechanism is 
employed. Referring now to FIG. 8C, a process that 
checks dates for rule retrieval includes retrieving 177 
a current date from a faring market that contains faring 
atoms with multiple, travel dates, and a stored date 
corresponding to a latest stored date that a result for 
the rule remains valid. The current date is compared 
178 to the stored date and if the rule still remains 
valid (i.e., the current date falls within a bound set 
by the stored date) the rule is not retrieved and 
instead rules that had been cached are used. If the 
stored date for the rule is not valid then a new rule is 
retrieved 179 and a new date is subsequently stored 180 
for the new rule. 

Referring now to FIG. 9, a process 134 for applying 
the rules retrieved with process 132 is shown. The rule 
application process 134 operates on each faring atom. 
The process 134 applies 181 the record-1 records to 
check for booking codes etc. The process 134 determines 
whether each record- 2 was cached in the faring atom. If 
a record-2 was cached in the faring atom, the process 
returns 183 the cached results. Otherwise, the process 
134 applies 184 the record_2 ' s for each of the stored 
record_2 categories. Rules provisions are expressed as 
" record- 2 s" , which are retrieved 132, as described in 
FIG. 8. These record-2s express logical relations over 
so called " record- 3 s" , which are records that contain 
detailed provisions. Individual procedures are provided 
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for evaluating each record- 3 as applied to a faring 
atom. Each record- 3 procedure returns either DEFER, 
FAIL, PASS , NO-MATCH or UNAVAILABLE, and these results 
are combined according to the logic in the record-2 to 
5 produce a result of either DEFER, FAIL or PASS for the 
entire record-2. The proper procedures for applying 
record- 3s and for combining their results according to 
record-2s are described in the ATPCO documentation. The 
"PASS" value is an extension used here since not all 
10 record-3s can be fully evaluated on the basis of the 

faring-atom alone. The RECORD-2 result is either PASS, 
FAIL or DEFER (the other two values are from record- 3s) . 

As a result of returning a cached result or of, the 
15 application of the recordj's, the process can return 
one of five possible results, "DEFER", "PASS", or "FAIL." 
The record as well as its results DEFER, PASS, or FAIL, 
are cached at 136 in the faring atom. The result FAIL 
causes the process 134 to exit 190. Whereas, returning 
20 a pass or a defer permits the process 134 to continue to 
examine remaining record-2s. A defer or pass result is 
stored 185 and it is determined 186 whether all record- 
2s have been processed. If all records have not been 
applied/examined if cached, the next record-2 is 
25 retrieved at 186a. After all record-2s have been 

examined, if pass results have been provided for all, 
the PASS result causes the process 134 to construct 188 
fare components and exit 190. If at least one DEFER 
result was returned process 134 constructs 188 the fare 
30 components, stores 189 deferred record-2 ' s in the faring 
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component and exits 190. The routines 188, 189 and 190 
thus correspond to the stored valid faring atom 
combination routine 138 (FIG. 7) . 

5 APPLICATION OF RECORD- 3 S 

The information contained in record- 3s varies by 
category. For example, category- 5 record-3s, which 
specify advanced-purchase restrictions, contain fields 
that specify how long in advance of travel time a fare 

10 must be reserved, how long after a reservation a fare 
must be purchased, and so on. Category-4 record- 3s, 
which specify flight-restrictions, contain fields that 
restrict flight -numbers, aircraft-type, airline, and 
whether flights are direct or non-stop. Every categrory 

15 has a different procedure for evaluating a faring-atom. 

As discussed above the record- 3 procedures that 
evaluate a faring-atom returns one of five values, and 
may return some other information such as discounts, 
penalties and surcharges . A value of PASS or FAIL can 

20 only be returned if that answer can be determined 

without examining any faring-atom other than the one the 
fare spans . 

The ATPCO rules distinguish between fare -component 
and priceable-unit restrictions. Most restrictions on 

25 travel route, flight -numbers , and aircraft- type are 

fare-component-based, i.e., restrict only the flights in 
the faring-atom governed by the fare. On the other 
hand, minimum and maximum- stay restrictions are 
priceable-unit -based, i.e., apply to joint properties of 

30 all the faring-atoms within a priceable-unit. A 
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minimum- stay requirement for a round- trip fare, for 
example, constrains the combination of outbound and 
return faring-atoms. Generally speaking, FC-based 
record- 3 s will be able to return either PASS or FAIL, 
5 while PU-based, restrictions may need to be deferred. 
Deferring rules means checking them at a later point, 
however. This is a more computationally expensive 
process, because it must be done for combinations of 
faring-atoms within a priceable-unit , and the number 
10 ways faring-atoms can be combined to create priceable- 
unit s can be quite large, and grows quickly with the 
size of the priceable-unit. For this reason, whenever 
possible it is desirable for record-3 application not to 
result in a value of DEFER. 
15 Many properties of faring-atoms can be bounded. 

For example, the earliest and latest departure- time 
within a faring-market, or within a slice, can be 
recorded, as well as the minimum and maximum number of 
connections within the faring-market and so forth. This 
20 information can often be used to evaluate priceable-unit 
restrictions at the fare -component level. A simple 
example of this is given below. 
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In this example, it is assumed that a certain fare's 
rules require at least a 3 -day layover at the; 
intermediate point of a round-trip priceable-unit , 
measured from the departure- times of the fare- 
5 components. The fare is used for the first half 
(outbound travel) of the priceable-unit, in the NW 
CHIJVISP faring -market in slice 1-. If there are exactly 
two slices in the query, then the fare -component that 
covers return travel must come from the NW MSP_CHI 
10 f aring-market in slice 2. .Suppose that the following 
faring-atoms exist (TABLE 13). (The airport ORD is in 
the city Chicago.) 

TABLE 13 



Slice 1 NW CHI_MSP. faring-atoms 


Slice 2 NW MSP_CHI faring-atoms 


ORD_MSP NW220..12APR97 13:00 


MSP_ORD NW301 15APR97 19:00 


ORD_MSP NW220 13APR97 13:00 


MSPJ3RD NWS77 16APR97 12:00 


ORDJ4SP NW220 14APR97 13:00 


MSP_0RD NW301 16APR97 19:00 



15 In each f aring-market , the earliest and latest 

departure -times can be calculated. In this case, the 
earliest departure- time in the slice-2 NW MSP_ORD market 
is 15APR97 19:00, and the latest departure- time is 
16APR97 19:00. 

20 When the minimum- stay requirement restriction is 

applied to the first faring- atom, its departure time of 
12APR97 13:00 can be compared to the two outer bounds on 
return- travel departure- time , 15APR97 19:00 and 16APR97 
19:00. In this case, the minimum-stay requirement is 

25 met even for the earliest possible return travel time, 
so the faring-atom unconditionally ' passes the 
restriction. Similarly, for the third faring-atom, 
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since the restriction fails even for the latest possible 
return- travel departure- time , the faring- atom 
unconditionally fails the minimum-stay requirement. But 
for the second faring-atom, because the restriction 
5 fails for the earliest possible return time, but passes 
the latest possible return time, it is necessary to 
defer the application of the restriction. 

GENERAL TIME BOUNDS 
10 Many priceable-unit-based categories restrict 

times. Categories 3, 5, 6, 7, 8, 9, 10 and 14 are 
usually priceable-unit-based. Categories 3 and 14 
usually restrict the departure-date of the first fligjat^* 
in a priceable-unit . Category 5 specifies how far in 
15 advance of travel fares must be purchased, and this :: is 
usually measured from the departure -date of the first 
flight in a priceable-unit. Categories 6 and 7 specify 
minimum and maximum- stays at stopovers within a 
priceable-unit. 
20 In many cases these categories do not need to be 

deferred. This is especially true if, as in the above 
example, time-bounds are known for other faring -markets 
in the journey, and the range of faring -markets that 
might enter into a priceable-unit with the faring-atom 
25 in not great. It is a relatively simple matter to 

record for each f aring-market the earliest and latest 
departure -date of any faring-atom within the faring- 
market. This can be done as faring-atoms are 
constructed. The problem remains of how to know what 
30 other f aring-markets might participate in a priceable- 



WO 00/02152 



PCT/US99/14961 



37 

unit with the faring-atom at hand, 
CATEGORY- 3 

Pseudo code for an example of a procedure that 
5 implements record- 3 category- 3, "Seasonality 

Restrictions" is shown in TABLE 15. Each category-3 
record-3 an example- of which is shown in TABLE 14 
specifies a permissible date range for travel, via a 
start -date and an end-date, either of which may be left 

10 blank. The default interpretation of category-3 is that 
these date restrictions apply to the departure-date of 
the first flight of the priceable-unit . This 
interpretation can be modified in two ways. First, if a 
certain field is set, then the category becomes fare- 

15 component based. In other words, the date restrictions 
apply to the departure -date of the first flight within 
the fare -component . Second, a geographic specification 
may be provided that alters the measurement of the 
departure - date . For example , the geographic 

20 specification may dictate that the relevant date is the 
departure-date of the first transoceanic flight. 

Category-3s (TABLE 14) also includes a field that 
specifies whether the record-3 is available. If it is 
not, that is an indication that some information is 

25 missing and the record-3 should not be used for pricing 
a ticket. In this case, the record-3 application must 
return UNAVAILABLE. Finally, a category-3 may include a 
specification of a date range that the category-3 is 
valid for. If travel is outside of these dates, the 

30 record-3 application must return NO - MATCH . 
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Category-3 field 


Example 


Earliest Permitted Travel Date 


nil 


Latest Permitted Travel Date 


190CT97 


Fare -Component Based 


false 


Geographic Specification 


nil 


Earliest Record- 3 Valid Date 


15MAY88 


Latest Record- 3 Valid Date 


nil 


Available 


true 



5 The logic of the procedure that processes the 

record-3 is as follows. If the record-3 is not 
available, UNAVAILABLE is returned. If travel is 
outside of the valid date-range of the record-3, NO- 
MATCH is returned. Then, processing branches depending 
10 on whether the record-3 is priceable-unit based (the 
default) , or fare -component based. If fare -component 
based, and there is no geographic specification, the 
departure date of the faring-atom is compared to the 
date-range of the record-3, and either PASS or FAIL is 
15 returned. If a geographic specification is provided, 
then this is used to compute the relevant travel date, 
and the same procedure applies. If, on the other hand, 
the record-3 is priceable-unit based, then broad time- 
bounds checks are used. If there is no geographic 
20 specification, the earliest and latest possible 
priceable-unit departure-dates are retrieved and 
compared to the date-range of the record-3. If they 
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both succeed, PASS is returned. If they both fail, FAIL 
is returned. Otherwise DEFER is returned. Finally, if 
the record-3 is priceable-unit based and includes a 
geographic specification, then DEFER is returned. The 
following pseudo-code implements the processing of 
record-3 category- 3 in the case where the record-3 must 
be evaluated given only a single faring-atom from the 
priceable-unit . 



TABLE 15 



appiy-recora-3-hC-category-3(recora-3, faring-atom, passenger-information, current-date) 

if (record-3 .available = false) 

retum(unavailable ) 
Let date = departure-date(faring-atom) 

If ((record-3.eartiest-record-3-valtd-date <> nil and record-3.earliest-record-3-valid-date > date) or 

( record-3 Jatest-record-3-valid-date <> nil and record-3. latest-record-3-valid-date < date)) 
return (no-match)) 

If (record-3.fare-component-based = true) 
Let travel-date = date 

If (record-3.geographic-specification <> nil) 

travel-date = apply-geographic-specification(record-3 .geographic-specification, faring-atom) 
If ((record-3.eariiest-perrnitted-travel-date <> nil and record-3. earliest-permitted-travel-date > travel-date) or 

(record-3. latest-perrnitted-travel-date <> nil and record-3Jatest-perrnited-travel-date < travel-date)) 

retum(fait) 

Else 

retum(pass) 
Else If (record-3. geographic-specification <> nil) 
retum(defer) 

Else 

Let earliest-travel-date = earliest-priceable-unit-departure-date(faring-atom) 
Let latest-travel-date * latest-priceabte-unit-departure-date(faring-atom) 
Let result = pass 

If (record-3.eartiest-perrnitted-travel-date <> nil) 

If (recxird-3. earliest-permitted-travel-date > latest-travel-date) 
result - fail 

Else If (record-3. earliest-permitted-travel-date <= earliest- travel-date) 

result = defer 
If (record-3. latest-permitted-travel-date <> nil) 

If (record-3. latest-permitted-travel-date < eariiest-travei-date) 

result = fail 

Else If (result <> fail and record-3.latest-permitted-travel-date >= latest-travel-date) 
result = defer 
retum(result) 

There can be another version of this application 
procedure, as shown in TABLE 16 dedicated to the case 
where all of the faring-atoms within the priceable-unit 



are known. This procedure is simpler, because there is 
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no need for time bound checks since all times are known 
exactly. This procedure is used to evaluate deferred 
record 3's (see TABLE 24). 



TABLE 16 



apply-record-3-PU-category-3(record-3, fares, faring-atoms. prime-faring-atom, passenger-information, current-date) 

If (record-3.available = false) 
retum(unavailable) 

Let date = departure-date(prirne-faring-atom) ^ t 4 , 

If ((record-3 earliest-record-3-valid-date <> nil and record-3.earliest-record-3-valid-date > date) or 

(record-3.latest-record-3-valid-date <> nil and record-3Jatest-record-3-valid-date < date)) 
retum(no-match)) 

Let travel-date = date 

If (record-3.fare-component-based = true) 

If (record-3.geographic-specification <> nil) 

traveWate = apply-geographic-specificaUon(record-3.geographic-speaficaton, pnme-fanng-atom) 

■ Else 

travel-date = departure-date(faring-atoms) 
if (record-3.geographic-specification <> nil) 

travel-date = apply-gec)graphic-spedftoUon(record-3.gTO fanng-atoms) 

If ((recor^3.eariiest-perrnitted-traveWate <> nil and record-S.eartiest-permitted-travel^ate > traveWate) or 
(record-3Jatest-permitted-travel-date <> nil and record-3.latest-permited-traveWate < travel-date)) 
return (fail) 

Else 

return(pass) 

Referring now to FIG. 10, the process 90 for 
constructing priceable units is shown. The term 
"priceable unit" as used herein represents a fundamental 

10 unit at which many fare restrictions apply. For 

example, round trip fares often include minimum stay 
requirements and these can only be expressed when both 
an outbound and a return faring atom are combined. This 
occurs at the level of the priceable unit. 

15 The process 90 of constructing priceable unit cores 

and pricing unit labels is organized as several nested 
procedures as follows. The process enumerates 200 a 



WO 00/02152 



PCT7US99/14961 



41 

collection of faring markets. Collections of faring 
markets are enumerated 200 with each faring market from 
a different slice by an algorithm that depends on the 
type of a priceable unit that is constructed. For 

5 example, for, a round trip priceable unit two faring 

markets are chosen on the same carrier and between the 
same cities but in opposite directions. The process 90 
also enumerates collections of sets of faring components 
at 202. For each faring market in a collection of 

10 faring markets its faring components are partitioned 

into sets of fare components that have the same fare and 
the same combinability record-2s. Collections of these 
sets are enumerated with one set chosen from each faring 
market resulting in. a collection of fares and associated 

15 collection of sets of fare components. At this 

juncture, any combinability record 2-s are evaluated to 
insure that the fares may be used together in a 
priceable unit . 

The process 90 also enumerates 204 collections of 
20 fare components. Thus, given a collection of sets of 
fare components from 202, the process evaluates any 
deferred record 2-s on collections of fare components in 
the enumeration process 204. These collections are 
constructed by selecting one fare component from each 
25 set. The process of evaluating deferred rules on 

collections of fare components outputs results in the 
form of a list of factored representations of priceable 
units. Thus, the output is a logical OR of logical ANDs 
of logical ORs of fare components. 

30 From the factored representations produced in 2 04 
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the process produces priceable-unit-labels 206 and 
priceable-unit-cores 208 with some sharing occurring 
between these structures to ensure that the number of 
priceable-unit-cores and priceable-unit -labels is kept 
5 to a minimum,. 

The pseudo-code below (TABLE 17) summarizes 
enumerating collections of faring markets process 200. 
It takes as input a set of sets of f aring-markets , 
containing one set per slice. These are the faring- 
10 markets generated by the calls to "create-divisions" (120 
FIG. 6) , as described above. 

TABLE 17 
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create-priceable-units(faring-market-sets) 

Let number-of-slices = tength(faring-market-sets) 
Let priceable-unit-labels = 0 

For slice-numberl from 1 to number-of-slices 

For faring-marketl in faring-market-sets[slice-numberl ) 

Let airline = faring-marketl .airline 

// Crelte one-way priceable-units. 

priceable-unit-labels = create-PUs-in-marketsl (faring-marketl. priceable-unit-labels, one-way) 
For slice-number2 from slice-numberl + 1 to number-of-slices 

For faring-market2 in faring-markets-on^mer(faring-rnarket-setstslice-number2], airline) 
// Create single and double open-jaws. 

priceable-unit-labels = create-PUs-in-makets2(faring-market1. faring-market2, 

priceable-unit-labels. open-jaw) 

If (faring-marketl .destination-city = faring-market2.origin-city) 

// Create round-trips and circle-trips of size 2. 

If (faring-market2.destination = faring-marketl .origin) 

priceable-unit-labels = create-PUs-in-markets2(faring-market1, faring-market2. 

priceable-unit-labels. round-trip) 
priceable-unit-labels = create~PUs-in-markets2(faring-market1, faring-market2, 

priceable-unit-labels, drcJe-trip2) 

For stice-number3 from stice-number2 + 1 to number-of-slices 

For faring-market3 in faring^arkets-on-carrier(faring-market-sets[siice-number3l, airline) . 
I f (f aring-market2.destination-city = faring-market3.origin-city ) 
// Create circle-trips of size 3. 

If (faring-market3.destinatiorvcity = faring-marketl .origin-city) 
priceable-unit-labels = 

create-PUs-in-markets3(faring-market1, faring-market2, faring- 

// 

// More iterations for circle-trips of lengths 4 and 5. 

// 



// Store priceable-unit-labels in faring-atoms. 
For priceable-u nit-label in priceable-unit-labels 

For faring-atom-set in priceable-unit-label.faring-atom-sets 
For faring-atom in faring-atom-set 

faring-atom. priceable-unit-labels += priceable-unit-label 



This pseudo-code iterates over f aring-markets in 
different slices, and passes faring markets to one of 
several possible create-PtJs-in-jnaricets procedures. 
5 These procedures vary by size of priceable-unit 

produced. The code ensures that the f aring-markets are 
in the correct format for the type of priceable-unit 
produced, and that the priceable units are all on the 
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same airline. This last restriction is motivated by 
efficiency since rarely do carriers permit priceable- 
units with fares from more than one airline. 

Each call to create-PUs-in-markets returns an 
5 updated set 'of priceable-unit-labels. At the end of the 
procedure, these priceable-unit-labels are stored in 
their component f aring-atoms . 

There are many other combinability restrictions 
that limit the manner in which fare components can be 
10 combined into priceable continuous units. Even when 
searching for fares for a small number of itineraries, 
there can be a very large number of possible pricing 
units because of the large number of possible fares that 
can exist. It is preferred to represent these priceable 
15 units in a compact manner so as to minimize the 
computation involved in their construction. 

The faring algorithm does not actually construct a 
data-structure for every priceable-unit . Instead, 
priceable-uni'ts are represented by a combination of two 
20 data structures: priceable-unit -cores (PU-cores) and 
-priceable-unit-labels (PU-labels) . PU-core data 
structures contain all the information associated with 
an individual priceable-unit except its f aring-atoms . 
Thus, each PU-core contains a set of fares (one fare per 
25 fare -component in the priceable-unit) and any other 
information associated with those fares, such as 
discounts, surcharges and penalties. PU- label data 
structures compactly represent connections between 
faring -atoms and PU-cores. 
30 At this stage of processing, a collection of fares 
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has been fixed on, and for each fare there is a set of 
fare -components . Priceable-units are constructed by- 
selecting one fare -component from each set and 
evaluating any deferred rules. The simplest manner that 
5 this could tie accomplished would be to enumerate 

complete collections of fare -components and to apply the 
deferred record-2s -from within, these fare -components . 
Often, this method can be made more efficient in some 
cases by use of the function get-OR-AND-OR-form as will 

10 be described. That function takes a collection of sets 
of fare -component s , evaluates any deferred rule- 
conditions, and returns a representation of the set of 
valid priceable-units. This representation is in OR- 
AND-OR form. In other words, it takes the form of a set 

15 of collections of sets of fare -component s . This is very 
close to a set of priceable-unit -labels except that 
since the sets are of fare -components rather than 
f aring-atoms, there are no PU-cores. The inner sets of 
fare -components returned by get -OR -AND -OR- form are 

20 guaranteed to have the same fares, surcharges, 
discounts, penalties and so on. 

PU-cores and PU- labels are constructed from the 
output of get-OR-AND-OR. The pseudo-code below 
summarizes this procedure. It iterates over the inner 

25 AND -OR form, constructing PU-cores (if no identical PU- 
core already exists) and PU-labels (if no identical PU- 
label already exists) . PU-labels are constructed by 
mapping from fare -components to f aring-atoms . PU-cores 
are stored on PU-labels.. 



30 
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TABLE 18 



create-PUs-from-far^components(faring-markets, fares, fare-component-sets, existing-PU-labels, 

environmental-information) 

Let slice-numbers = 0 

Let PU-labeis = existing-PU-labels 

Let PU-cores = 0 

For faring-market in faring-markets 

slice-numbers += faring-marketslice-number 

For AND-OR in get-OR-AND-OR(faring-markets. fare-component-sets, environmental-information) 
// 

// AND-OR is a collection of sets of fare-components, representing alt the pnceable-units 

// that can be constructed by choosing one fare-component from each set 

// 

Let PU-core = nil 
Let surcharges = 0 
Let faring-atom-sets = 0 

For fare-component-set in AND-OR 

surcharges += first(fare-component-set).surcharges 

Let faring-atom-set = 0 

For fare-component in fare-component-set 

faring-atom-set += fare-componentfaring-atom 
faring-atom-sets += faring-atom-set 

// Rnd an existing PU-core with these fares and surcharges, or construct a new one. 
For test-PU-core in PU-cores 

If (test-PU-core.surcharges = surcharges) 
PU-core = test-PU-core 
tf (PU-core = nil) 

PU-core = new-PU-core() 

PU-core.fares = fares 

PU-core.surcharges = surcharges 

PU-core.slice-numbers = slice-numbers 

// Find an existing PU-label with these faring-atoms. or construct a new one. 

Let PU-label = nil 

For test-PU-label in PU-labeis 

If (test-PU-label.faring-atom-sets = faring-atom-sets) 
PU-label = test-PU-tabel 
If (PU-label = nil) 

PU-label = new-PU-labelO 

PU-label. faring-atom-sets = faring-atom-sets 

PU-label.slice-numbers = slice-numbers 

PU-label.priceabie-unit-cores = 0 

PU-labeis += PU-label 

PU-label .priceable-unit-cores ♦= PU-core 
retum(PU-iabels) 



5 



To understand the role PU-cores and PU- labels play 
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in the faring algorithm, it may be helpful to look at an 
example, involving a round- trip journey between BOS and 
MSP. In this example, there are four outbound 
itineraries and four return itineraries, each of which 
5 is spanned by a single f aring-market . For both the 
outbound and return itineraries, there is a choice 
between two airlines, UA and NW. Both of these airlines 
offer two round-trip fares and one one-way fare. This 
situation is summarized in TABLE 19 below. 

10 

TABLE 19 



Fa ring -market 


Faring -Atoms 


Fares 


Slice 1: UA 
BOS-MSP 


BOS-MSP UA100 
BOS-MSP UA200 


UA BOS-MSP RT U Q M 
UA BOS-MSP RT "M14" 
UA BOS-MSP OW "Y" 


Slice 1: NW 
BOS-MSP 


BOS-MSP NW3 00 
BOS-MSP NW4 00 


NW BOS-MSP RT "HE7" 
NW BOS-MSP RT "Q7NR" 
NW BOS-MSP OW U F" 


Slice 2: UA MSP-BOS 


MSP-BOS UA111 
MSP-BOS UA222 


same as for the outbound 
UA f aring-market 


Slice 2: NW MSP-BOS 


MSP-BOS NW333 
MSP-BOS NW444 


same as for the outbound 
NW f aring-market 



Assume that in each of the four f aring-markets 
15 (i.e., BOS-MSP UA, BOS-MSP NW, MSP-BOS UA and MSP-BOS 
, fare-components have been constructed for every 
combination of faring -atom and fare. The fare- 
components built from the fare "NW BOS-MSP RT HE 7" 
contain a deferred record-2 that is checked during 
20 priceable-unit construction. This record-2 does not 

permit outbound travel on flight "NW30 0" combined with 
return travel on flight H NW444." When constructing 
round- trip priceable -units , round- trip fares are 
combined with like round-trip fares. This situation 
25 permits the construction of a total of 23 priceable- 
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units, as shown in TABLE 20. 

TABLE 20 



Priceable-Unit 
Number and 
Type 


Slice-l Faring- 
Atom 


Slice-l 
Fare 


Slice-2 
Faring-Atom 


Slice- I 
2 Fare 1 


1 Round- trip 


BOS-MSP UA100 


RT "Q" 


MSP— BOS UA111 


RT Q 


2 Round- trip 


BOS-MSP UA100 


RT U M14" 


MSP-BOS UA111 


RT 
nx *± 


3 Round- trip 


BOS-MSP UA100 


RT U Q* 


MSP-BOS UA222 


RT *Q" 


4 Round- trip 


BOS -MSP UA100 


RT *M14" 


MSP-BOS UA222 


RT 

**M1 4** 


5 Round- trip 


BOS-MSP UA200 


K. 1 


PIS t* DVJO \Jr\~i. X J. 


RT W Q" 


6 Round- trip 


BOS -MSP UA200 


tC 1 1*1 X 1 


woo -one itai i i 


RT 

M M14" 


7 Round- trip 


BOS-MSP UA200 


RT tt Q" 


MSP-BOS UA222 


RT "Q w 


8 Round- trip 


BOS-MSP UA200 


RT U M14" 


MSP-BOS UA222 


RT 

^14* 


9 Round- trip 


BOS-MSP NW300 


RT "HE7NR" 


MSP-BOS NW333 


RT 

M HE7|* 


10 Round- trip 


BOS-MSP NW300 


RT "Q7NR" 


MSP-BOS NW333 


RT v.. 
"Q7NR" 


11 Round- trip 


BOS-MSP NW300 


RT "QIWRT 


MSP-BOS NW444 


RT 

"Q7NR" 


12 Round- trip 


BOS-MSP NW400 


RT **HE7NR* 


MSP-BOS NW333 


RT 

"HE 7** 


13 Round- trip 


BOS-MSP NW400 


RT •*Q7NR" 


MSP-BOS NW333 


RT 

"Q7NR" 


14 Round- trip 


BOS-MSP NW400 


RT "HE7NR" 


MSP-BOS NW444 


RT 

"HE7-" 


15 One-way 


BOS-MSP NW4 00 


RT **Q7NR" 


MSP-BOS NW444 


RT 

M Q7NR W 


16 One-way 


BOS-MSP UA100 


OW "Y" 






17 One-way 


BOS-MSP UA200 


OW tt Y" 






18 One-way 


BOS-MSP NW300 


OW tt F" 






19 One-way 


BOS-MSP NW400 


OW "F" 






20 One-way 






MSP-BOS UA111 


OW " Y" 


21 One-way 






MSP-BOS UA222 


OW M Y° 


22 One-way 






MSP-BOS NW333 


OW "F* 


23 One-way 






MSP-BOS NW444 


OW *F" 



5 

Even in this example, the list of possible 
priceable-units is long (23 units) . The reason that 
there are so many priceable-units is because production 
of priceable-units involves several choices (of fares 
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and faring- atoms) . 

In TABLE 21 below, each entry represents a choice 
(an OR) of either faring -atoms or PU-cores. Each row 
represents a collection (an AND) of these choices. And 
finally, the. entire table represents a choice (an OR) 
over these collections. Collectively, this OR-AND-OR 
table provides a compact representation of the 2 3 
priceable-units . 



TABLE 21 



Label 
■Number 


Slice-1 Faring- 
Acom Options 


Slice-2 Faring-Atom 
Options 


Priceable-Unit-Core 
Options 


1 


BOS-MSP UA100 
BOS-MSP UA200 


MSP-BOS UA111 
MSP-BOS UA222 


Xi RT "Q", 2: RT u Q m 
1: RT "M14", 2: RT 
^14* 


2 


BOS-MSP NW300 
BOS-MSP NW400 


MSP-BOS NW333 
MSP-BOS NW444 


1: RT "Q7NRV 2: RT 
"Q7NR" 


3 


BOS-MSP NW300 


MSP-BOS NW333 


1: RT "HE?", 2: RT 
"HE7" 


4 


BOS-MSP NW400 


MSP-BOS NW333 
MSP-BOS NW444 


1: RT "HE7\ 2: RT 
"HE7- 


5 


BOS-MSP UA100 
BOS-MSP UA200 




1: OW "Y n 


6 


BOS-MSP ,NW300 
BOS-MSP NW400 




Is OW "F" 


7 




MSP-BOS UA111 
MSP-BOS UA222 


2: OW *Y" 


, 8 




MSP-BOS NW333 
MSP-BOS NW444 


2: OW M F W 



Each row of TABLE 21 is a priceable-unit- label (PU- 
label) , an object that factors a set of priceable-units 
into a collection of choices that have no further 
dependencies. There is a choice for every faring-atom 
involved in the priceable-unit, and a choice of a 
priceable-unit -core (PU-core) . Each PU-core contains 
the same number of fares as there are faring-atom 
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choices. In the case where there are no constraints 
between faring-atoms in different slices, PU- labels are 
a very compact representation of priceable-units . PU- 
label #1, for example, represents a total of eight 

5 different priceable-units.' In cases where there are 
interactions between the faring-atoms in different 
slices, several PU-"labels can be produced for a single 
PU-core. An example of several PU-labels is shown for 
the NW RT "HE7" fare represented by PU-labels numbers 3 

10 and 4. These priceable-unit-labels and priceable-unit- 
cores are used by the linking procedure 94 (FIG. 4B) to 
associate itineraries from more than one slice to fares. 

ENUMERATING COLLECTIONS OF SETS OF FARE - COMPONENTS 
15 Each of the f aring-markets that is passed to 

create -PUs- in -markets has a set of fare -components 
produced by applying fare rules procedure 88. 

Referring now to FIG. 10A, enumerating collections 
of sets of fare -components 202 (described by pseudo-code 
20 below) partitions the fare -components in each faring- 

market into sets such that every fare -component in a set 
has the same fare and the same combinability record-2s. 

Fare combinability restrictions are specified in 
record- 2s rule category 10. Any category-10 record-2s 
25 in a fare's rules is stored in the combinability -record- 2 
field in the fare -component s . 

Once fare -components are partitioned 2 02a into 
sets, collections of these sets are enumerated 202b, by 
selecting one set from each f aring-market . For each 
30 fare there is a choice of fare -components . At this 
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point, when the fares within a priceable-unit have been 
fixed, any category- 10 record-2s that was deferred is 
applied 2 02c to determine whether the fares may be used 
together in a priceable-unit. This is accomplished by 
5 applying 20?c each fare's combinability record-2 (if it 
has one) to every other fare within the priceable-unit. 

The code below (TABLE 22). is written for two 
f aring-markets within a priceable-unit, as would be the 
case for round- trips, open jaws and circle- trips of size 
10 two. Similar code would be used for priceable-units of 
other sizes . 
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TABLE 22 



partition-fare-components-into-sets(faring-market) 

// Partition fare-components into sets based on fare and combinability record-2. 
// 

Let fare-component-sets - 0 

For fare-component in faring-marketfare-components 
Let fare = fare-componenUare 

Let combinability-record-2 = fare-component combinability-record-2 

Let previous-set = nil 

For test-set in fare-component-sets 

Let test-fare-component = first(test-set) 
If ((fare = test-fare-component.fare) and 

(combinability-record-2 = test-fare-componentcombinability-record-2)) 
previsous-set = test-set 
If (previous-set = nil) 

fare-component-sets += tist(fare-component) 

Else 

previous-set += fare-component 
retum(f are-compone n t-sets ) 



create-PUs-in-manxets2(faring-market1. faring-market2. existing-PU-labels. PU-type. environmental-information) 

Let fare-component-sets1 = partition-fare-components-into-sets(faring-marketl) 
Let fare-component-sets2 = partition-fare-components-into-sets(faring-market2.) 
Let PU-labels = existing-PU-labels 

For fare-componentsl in fare-component-setsl 

For fare-components2 in fare-component-sets2 

Letfarel 3 first(fare-components1 ).fare 
Let fare2 = first(fare-components2).fare 

Let combinability-record-2-1 = ftrst(fare-components1).combinabiiity-record-2 
Let combinability-record-2-2 = first(fare-components2).combinability-record-2 

// Check fare combinability requirements, by applying each fares's combinabilty 
// record-2 to all the other fares within the priceable-unit 

If ((combinability-record-2-1 = nil or 

apply-combinabiiity-record-2(combinabrtity-record-2-1. fare2. PU-type) = pass) and 

(combinability-record-2-2 = nil or 

apply-combinability-record-2(combinability-record-2-2. farel . PU-type) = pass)) 

PU-labeis - create-PUs-from-fare-components(list(faring-market1 . faring-market2), 

Iist(fare1 . fare2). 

list(fare-components1. fare-components2), 
PU-labels, environmental-information) 

retum(PU-labels) 

The procedure create -PUs-in-markets2 , after it has 
selected two fares and two sets of fare -components and 
verified fare combinability restrictions, calls the 
5 procedure 202d create-PUs- from- fare-components to 

evaluate deferred rules and construct priceable-unit - 
labels and priceable-unit - cores . 
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CONSTRUCTING PRICEABLE- UNITS 

At this stage of processing, a collection of fares 
is determined, and for each fare there is a set of fare- 
5 components. Priceable-units are constructed by- 
selecting one fare -component from each set and 
evaluating any deferred rules. * 

Referring now to FIG. 11, a process 204 to 
enumerate collection of fare components is shown. The 

10 process 204 can enumerate 212 a collection of sets of 

fare -component s , enumerate fare components by selecting 
one component from each set, apply or evaluate 216 any 
deferred rule -conditions , and return a compact 
representation 218 of the set of, valid priceable-units. 

15 A preferred technique to accomplish this uses a 

w GET_OR_AND_OR" operation described below TABLES 24, 26 
and 2 7 . 

The representation process 218 produces an OR-AND- 
OR representation of the priceable units. The process 

20 218 produces a set of collections of sets of fare- 

eomponents similar to that in FIG. 20, that will later 
be transformed into priceable-unit-labels and priceable- 
unit-cores by processes 206 and 208. described further in 
TABLE 22. The inner sets of fare -components returned by 

25 get-OR-AND-OR-form have the same fares, surcharges, 
discounts, penalties and so on. 

The procedure 218 get-OR-AND-OR, takes a collection 
of fare -component sets and enumerate collections of 
fare -components by selecting one from each set. It 
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evaluates any deferred record-2s, and constructs a set 
of valid priceable-units. This set is transformed into 
a factored OR-AND-OR form, and returned. 

Referring back: to FIG. 10, PU-cores and PU-labels 

5 are construqted 210 at process 206 and 208 from the 
output of get -OR-AND-OR process 204. The pseudo-code 
below and FIGS. 12-13 summarizes this procedure. 
Construction 210 iterates over the inner AND-OR form, 
producing PU-cores 206 (if no identical PU-core already 

10 exists) and PU-labels 208 (if no identical PU-label 
already exists) . PU-labels are produced by mapping 
fare -components to f aring-atoms and PU-cores are stored 
on PU-labels. 

15 FACTORING PRICEABLE- UNITS 

Referring now to FIGs 12-15, the get-OR-AND-OR 
process 218 to construct the priceable unit 
representation is shown and is also described in detail 
below through* pseudo- code . As shown in FIG. 12 and in 

20 pseudo-code in TABLE 23 below, three different high- 
level procedures are used, depending on whether 
priceable-units are one 220, two 222, or three or more 
224 fare-components. 

25 TABLE 23 



get-OR-AND-OR(faring-markets, fare-component-sets, environmental-information) 

Let size = length(faring-markets) 
lf(size = 1) 

retum(get-OR-AND-OR-1(faring-markets. fare-component-sets, environmental-information) 
Else If (size = 2) 

return(get-OR-AND-OR-2(faring-markets. fare-component-sets, environmental-information) 

Else 

return(get-OR-AND-OR-3+(faring-markets, fare-component-sets, environmental-information) 
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Two auxiliary functions are used in the get-OR-AND- 
OR procedures. The first, apply-deferred-record-2s 
218a, takes a collection of fare-components (a potential 
5 priceable-unit) and evaluates any deferred record-2s 
they might have. In contrast to the initial stage of 
rule application, here all the. fares and faring-atoms 
within the priceable-unit are known. It returns either 
PASS, FAIL or DEFER (in this case, DEFER means that the 
10 record-2s cannot be evaluated even at the priceable-unit 
level: they involve journey- level constraints). In such 
a case the priceable-unit is not produced (TABLE 24.) 

TABLE 24 

apply-deferred-record-2s(fare-components. environmental-information) 

Let taring-atoms = 0 
Let fares = 0 

For fare-component in fare-components 
fares += fare-componentfare 
faring-atoms ♦= fare-componenLfaring-atom 

For fare-component in fare-components 

For record -2 in fare-component.deferred-record-2s 

If (apply-record-2-PU(record-2, fares, faring-atoms, fare-component. faring-atom, 
environmental-information) 

opass 
retum(fait) 

retum(pass) 

15 The second auxiliary function, partition- fare- 
components-by-surcharges 218b, (TABLE 25) takes a set of 
fare -components and partitions it into subsets that have 
the same secondary characteristics: the same surcharges, 
discounts, penalties, etc. 



20 
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TABLE- 25 



partition-fare-components-by-surcharges(fare-components) 
"Let partitions = Q 

For fare-component in fare-components 
Let found-partition = false 
Let surcharges 3 fare-componentsurcharges 
For partition in partitions 

If (first(partition).surcharges = surcharges) 
found-partition = true 
partition +- fare-component 
If (found-partition = false) 

partitions += Hst(fare-component) 

return (partitions) 



FACTORING PRICEABLE-UNITS OF SIZE ONE 

Referring now to FIG, 13 , the get-OR-AND-OR :J 
5 function 23 0 for priceable-units of one fare -component 
(one-way priceable-units) is shown. It is passed only a 
single fare -component set 232, and applies 216 deferred 
record-2s. The final set of valid fare -components is 
partitioned 23 4 into sets with the same surcharges, 
10 penalties, and discounts. The partitioned sets are 
~ placed into the proper OR-AND-OR representation 236. 

The procedure PU-1 for a priceable unit of size 1 
is set out in TABLE 26. 
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TABLE 2 6 



get-OR-AND-OR-1 (faring-markets. fare-component-sets. environmentaMnformation) 

Let valid-fare-components = Q 

For fare-component in first(fare-component-sets) 

tf (apply-deferred-record-2s(list(fare-component), environmentaMnformation) 
valid-fare-components += fare-component 

Let OR-AND-OR = 0 

For OR in partition-fare-components-by-surcharges(vaiid-fare-components) 
Let AND-OR = list(OR) 
OR-AND-OR += AND-OR 

retum(OR-AND-OR) 



5 FACTORING PRICEABLE -UNITS OF SIZE TWO 

Two - component priceable- units include . round- trips . 
and two-component open- jaws and circle- trips . They are 
common and should be computed efficiently and 
represented compactly. The function get -OR-AND-OR- 2 240 

10 efficiently computes and represents two component 

priceable units. Combinations of fare -components are 
not enumerated unless it is necessary for evaluation of 
-deferred record-2s. The resulting set of priceable- 
units is also represented in a compact OR-AND-OR form. 

15 Pseudo code for the get-OR-AND-OR-2 procedure is 

set forth below (TABLE 27) . The process 24 0 enumerates 
priceable units 24 8 by selecting one fare component from 
each set. The get-OR-AND-OR-2 process 240 tests 
deferred record-2s and, if the test is passed, adds the 

20 resulting valid priceable unit to the OR-AND-OR 
representation . 
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TABLE 27 



get-OR-AND-OR-2(faring-markets. fare-component-sets, environmental-information) 
Let OR-ANO-OR - 0 

Subroutine find-AND-OR(surcharges1 , fare-component-set2) 
// 

// Return any AND-OR from OR-ANO-OR that has fare-components with surcharges surchargesl in its 
// first set of fare-components, and has fare-component-set2 as its second set of fare-components. 
// 

For AND-OR in OR-AND-OR 

If (first(first(AND-OR)).surcharges =* surchargesl and second(AND-OR) = fare-component-set2) 
retum(AND-OR) 

retum(nil) 

Subroutine add-unifomi-cross-product(fare-component-set1, fare-component-set2) 

// 

// Add the priceable-units that can be had by selecting one element from fare-component-setl and 
// one element from fare-component-set2. Both sets are uniform with respect to surcharges. 
// 

Let AND-OR = find-AND-OR(first(fare-component-set1).surcharges, fare-component-set2) 
If (AND-OR = nil) 

OR-AND-OR +- Iist(fare-component-set1 , fare-component-set2) 

Else 

first(AND-OR) = append(first(AND-OR). fare-component-setl ) 

Subroutine add-aoss-product(fare-component-set1 , fare-component-set2) 

// Add the priceable-units that can be had by selecting one element from fare-component-setl and 
// one element from tare-component-set2. 

Let uniform-fare-component-setsl = partition-farB-components-by-surcharges(fare-component-setl) 
Let unifbrm-fare-component-sets2 = partition-fare-components-by-surcharges(fare-component-set2) 
For uniform-fare-component-setl in unifonm-fare-component-setsl 

For uniforrn-fare-component-set2 in uniform-fare-component-sets2 

add-unifomi-cross-product(uniform-fare-component-setV unifomvfare-component-set2) 

Subroutine enumerate-priceable-units(fare-component-set1 . fare-component-set2) 

// Enumerate priceable-units by selecting one fare-component from each set Test deferred record-2s. 

// and if they pass, add the resulting priceable-unit to the OR-AND-OR representation. 

// 

For fare-component1 in fare-component-setl 
Let valid-fare-components2 = 0 

For fare-component2 in fare-component-set2 _ ^ 

If (apply-deferred-record-2s<list(fare-componentl. fare-component2). environmental-information)) 
vaiid-fare-components2 ♦» fare-component2 

If <valid-fare-components2 <> 0) 

add-cross-product(list(fare-component1), vaHd-fare-components2) 

Let fare-component-setl -with-njles = 0 
Let fare-component-setl -without-rutes = Q 
Let fare-component-set2-with-rules = 0 
Let fare-component-set2-without-rules = 0 



For fare-componentl in first (fare-component-sets) 
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If (fare-component1.deferred-record-2s = nil) 

fare-component-setl-without-rules += fare-comoonentl 

Else 

fare-component-set 1-with-ailes fare-component1 
For fare-component2 in second(fare-component-sets) 
If (fare-cornponent2.deferred-record-2s = nil) 

fare-component-set2-without-njles += fare-component2 

Else 

^ fare-component-set2-with-njles += fare-component2 

// There is no need to enumerate combinations of fare-components that have no deferred rules. 
add-cross-product(fare-component-set1-without-rules. fare-component-set2-without-ruies) 

// For the remainder of fare-components, though, explicit enumeration is necessary. 
enumerate-priceabte-units(fare»cornponent-set1-with-ruies, fare-cornponent-set2-without-rutes) 
enumerate-prtceable-units(fare-component-set1 , fare-component-set2-with-rules) 

retum(OR-AND-OR) 

FACTORING PRICEABLE-UNITS OF SIZE THREE OR GREATER 

Properly enumerating all possible combinations of 
fare -components for priceable-units of size three, or 
5 greater is computationally burdensome, though possible. 

Referring now to FIG. 15 , a preferred procedure 260 
finds a subset of possible priceable-unitis: In 
particular, it extracts 262 those fare -components that 
10 have no deferred record-2s, and build priceable-units 

^from them. Since there are no deferred record-2s, there 
are no intra-priceable-unit constraints and it is 
possible to construct a factored representation. 

Priceable-units of size three or greater tend to 
15 have more deferred record- 2s . This may somewhat reduce 
the effectiveness of the extracting procedure 262. The 
prevalence of deferred record-2s rules occurs because in 
complicated journeys, time-bounds used in an initial 
rule application tend to be broadly specified. 
20 At this stage of processing time bound ranges can 

% ■ 
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be tightened, because the f aring-markets that comprise 
the priceable-unit are known. Therefore, deferred 
record- 2s can be reapplied 2 64 to faring- atoms in the 
same manner that they are applied in the initial rule 

5 application. If all deferred record-2s pass, then the 
faring-atom is retained 266. If a record-2 fails or is 
deferred, the faring-atom is discarded. The function 
reevaluate -deferred -record- 2s (TABLE 28) performs this 
filtering. It takes a set of f aring-markets and a fare- 

10 component set, and sets time-bounds based on the f aring- 
markets . It reevaluates deferred record-2s for each 
fare -component in the set, and returns the set of fare- 
components that have all their record-2s pass. 

TABLE 28 

reevaluate-deferred-record-2s(faring-rrrarkets, fare-component-set, environmental-information) 

set-time-bounds(faring-markets) 
Let fare-components = 0 

For fare-component in fare-component-set 
Let result * pass 
Let deferred-reoord-2s = 0 
For record-2 in fare-componenLdeferred-record-2s 
Let record-2-resulL record-2-surcharges = 

apply-reccrd-2-FC(record-2. fare-componentfaring-atom. environmental-information) 
If (record-2-result = pass) 

fare-componentsurcharges += record-2-surcharges 
Else if (record-2-result = defer) 

deferred-record-2s ♦= record-2 

Else 

result = fail 
If (result = pass) 

fare-componentdeferred-record-2s = deferred-record-2s 
fare-components ♦= fare-component 

retum(fare-components) 

15 The procedure 2 68 that factors priceable-units of size 
three or greater, get-OR-AND-OR-3+ , (TABLE 29) applies 
reevaluate -de f erred- record- 2s to each set of fare- 
components, to filter them. It then partitions the 
resulting sets based on surcharges, and takes the cross - 

20 product of these sets to construct the proper OR-AND-OR 
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representation. The procedure for the last case does 
not return all possible valid priceable-units . 

TABLE 2 9 

get-OR-AND-OR-3+(faring-maricets, fare-compcnent-sets, environmental-information) 
Let OR-AND-OR = { 0 } 

For fare-component-set in fare-component-sets 

Let valid-fare-components = reevaluate-deferred-record-2s(faring-markets. fare-component-set 

environmental-information) 

Let new-OR-AND-OR = 0 

For OR in partition-fare-components-by-surcharges(valid-fare-cornponents) 
For prevtous-AND-OR in OR-AND-OR 

new-OR-AND-OR postpend(previous-AND-OR, OR) 
OR-AND-OR = new-OR-AND-OR 

retum(OR-AND-OR) 

5 

LINKING ITINERARIES 

. Priceable-units-labels associate faring-atoms from 
one or more slices with fares. In the pricing-graph 
representation 38' set of pricing solutions, sets of 

10 priceable-unit- labels are used to link itineraries from 
different slices. 

The pricing graph representation 38' of pricing- 
solutions 3 8 is constructed by selecting a set of 
priceable-unit-labels . Each of these PU-labels may or 

15 may not project onto a given slice of a journey. For 

example, in a round -trip journey a round- trip priceable- 
unit-label will project onto both slices, while a one- 
way priceable-unit-label will project onto only one 
slice of the journey. Once a set of PU-labels has been 

20 chosen,, in any slice any itinerary may be chosen so long 
as it has some division that has faring-atoms containing 
exactly the PU-labels that project onto that slice. The 
choice of itinerary is otherwise independent of choices 
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made in other slices. 

A set of PU- labels encodes all constraints that 
exist between itineraries in different slices. This 
leads to a relatively simple procedure for constructing 
5 the pricings-graph. Itineraries within each slice are 

indexed by the sets of multi-slice PU-labels they can be 
associated with. These indices are called slice- label - 
sets, and act as a logical OR over itineraries. The 
slice-label-sets from different slices are linked by 
10 matching PU-labels. 

Single-slice (one-way) priceable-unit-labels are 
treated somewhat differently than multi-slice priceable- 
unit-labels to enhance efficiency. In particular, there 
is no need to include single-slice PU-labels in slice- 
15 label-sets, because they do not need to be matched • 
across slices. Rather, single-slice PU-labels are 
attached closely to itineraries in the pricing-graph. 
That is, within a slice-label -set , each itinerary is 
associated with a compact representation of the set of 
20 single-slice PU-labels that can be used with the 

itinerary, given that the multi-slice PU-labels found 
within the slice-label-set are also used. 

The linking process constructs slice-label-sets 
with each slice-label-set being a set of multi-slice PU- 
25 labels and associated itinerary divisions. Slice-label- 
sets group itineraries by multi-slice PU-labels. Each 
division has associated with it a set of single-slice 
PU-labels. 

In the pricing -graph, slice-label-sets act as. ORs 
30 over itineraries. Multi-slice PU-labels encapsulate 
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information concerning the itinerary to permit the 
linking process to operate over slice-label-sets rather 
than individual itineraries. This approval is 
computationally efficient and results in small pricing- 
5 graphs. In each slice -label- set , each itinerary 

(division) is paired with a set of single-slice PU- 
labels. During construction of. the pricing graph, each 
slice-label -set is transformed into an OR over ANDs of 
itineraries and sets of PU-labels. 

10 The linking process also connects or links slice- 

label-sets from different slices, as shown in FIG. 16. 
Connecting is accomplished by starting from the first 
slice and working forward to the last slice. 
Intermediate results are summarized in open-label -sets . 

15 Each open- label -set is a set of (multi-slice) PU-labels 
that project onto slices that have not been processed, 
along with a set of backward- links that are each a pair 
of a slice-label-set and an open- label -set from the 
previous slice,. Processing starts with a single, empty 

20 slice-0 open-label-set 288. Slice-label-sets from slice 
1 are "added" 290 to this open- label -set , resulting in 
new slice-1 open- label- sets . Then slice-label -sets from 
slice-2 are added to these, resulting in slice- 2 open- 
label -sets, and so on. As this process continues, PU- 

25 labels that are complete 292 (i.e., that do not project 
to subsequent slices) are removed 298 from open-label- 
sets. If any pricing- solutions exist, the process will 
terminate 300 in a single, empty, last-slice open-label- 
set. At that point, the backward- links serve as the 

30 top-level representation of the pricing-graph. 
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Set forth below is an example of the linking 
process. This example assumes a three-slice circle-trip 
journey, from BOS to MSP to MIA. In the following 
discussion, PU-labels are identified by a unique letter 
5 followed by .a sequence of digits that indicate which 

slices the PU- label projects onto. For example, A-23 is 
a two-component PU-label that projects onto the second 
and third slices. Each itinerary may have several 
divisions, and each division may have many possible 
10 collections of PU-labels (with each collection built by 
selecting one PU-label per faring-atom in the division) . 

At this stage of processing in the faring process 
18 divisions have been produced for each itinerary, each 
division comprising a set of f aring-atoms . PU-labels - 

15 have been constructed, and stored in each faring-atom. 

From this information it is possible to enumerate for 
every division, possible collections of PU-labels, by 
selecting one for each faring-atom. TABLE 30 below 
summarizes the result of this procedure, for the example 
20 journey. Each possible collection of PU-labels is 

partitioned into those that project onto only one slice 
(one-way priceable-units) and those that project onto 
more than one-slice. In this table, divisions are 
encoded using the endpoints of f aring-atoms., to save 
25 space, and each itinerary and division are given numeric 
labels so that they can be referenced in the rest of the 
discussion. 



30 
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TABLE 3 0 



Slice Itinerary 


Division 


Multi-Slice 
PU- Labels 


Single- 
Slice 
PU- Labels 


1 


1.1 BOS-MSP 
UA123 


1.1.1 BOS-MSP 


{A- 123} 


{} 








{F-13} 


{} 








{ } 


{1-1} 


1 


1.2 BOS-CHI 
NW315 CHI_MSP 
UA73 9 


1.2:1 BOS-MSP; CHI -MSP 


{B-13 C-12} 


{} 








Iq.i ^ I 

(B-13 ) 


/ T_J 1 I 

(H-l ) 








{C-12} 


{G-l} 








r \ 
\ I 


{G-l H-l} 


1 


1.3 BOS-MSP 
CO4S0 


1.3.1 BOS-MSP 


{} 


{j-D 


2 


2.1 MSP-MIA 
UA901 


2.1.1 MSP-MIA 


{A-123} 


{} 








{ ) 


{K-2} 


2 


2.2 MSP- CHI 
UA623 CHI_MIA 
UA841 


2.2.1 MSP-MIA 


{A-123 } 


{ / 








I / 


(K-2 \ 






2.2.2 MSP-CHI; CHI -MIA 


{C-12 D-23} 


{} 








{C-12} 


{M-2} 








{D-23} 


{L-2} 








{) 


{L-2 M-2} 


2 


2.3 MSP-MIA 
FL207 


2.3.1 MSP-MIA 


{E-23) 


{} 


3 


3.1 MIA-BOS 
UA112 


3.1.1 MIA-BOS 


{A-123} 


{} 


3 


3.2 MIA- CHI 
UA487 CHI-BOS 
NW316 


3.2.1 MIA-CHI; CHI-BOS 


{D-23 B-13} 


{} 








{D-23} 


(0-3} 








{B-13} 


{N-3} 








{} 


{N-3 0-3} 


3 


3.3 MIA-MSP 
FL208 MSP-BOS 
UA558 


3.3.1 MIA-MSP; MSP-BOS 


{E23 F13} 


{} 








{E23} 


{P-3} 



As TABLE 3 0 above shows, there are three different 
itineraries for each slice. Each itinerary is split 
into one or two divisions of f aring-atoms . Each 
division has one or several possible PU- label 
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combinations. For example, for the second division of 
the second si ice -2 itinerary (2.2.2) there are four 
different PU-label sets. This is because the division 
has two f aring-atoms , and each faring-atom has two 
possible PU-labels. For reference, the table below 
lists each hypothetical PU-label along with its faring- 
markets. 



TABLE 31 



Name 


Far rng -Market s 


" ~ - - - - - 


— - - _ 


Comment j 


A- 123 


1: UA BOS-MSP 


2: UA MSP-MIA 


3: UA 

MIA-BO 

S 


3 -Component Circle 
Trip 


B-13 


1: NW BOS-CHI 




3: NW 
CHI -BO 
S 


Round Trip 


C-12 


1: UA CHI-MSP 


2: UA CHI -MSP 




Round Trip 


D-23 




2: UA CHI -MIA 


3: UA 

MIA-CH 

I 


Round Trip 


E-23 




2: FL MSP-MIA 


3: FL 

MIA-MS 

P 


Round Trip 


F-13 


1: UA BOS -MSP 




3: UA 

MSP-BO 

S 


Round Trip 


G-l 


1: NW BOS_CHI 






One Way 


H-l 


1; UA CHI-MSP 






One Way 


1-1 


1: UA BOS-MSP 






One Way 


J-l 


1: CO BOS -MSP 






One Way 


k-2 




2: UA MSP-MIA 




One Way 


L-2 




2: UA MSP-CHI 




One Way 


M-2 




2: UA CHI-MIA 




One Way 


N-3 






3; UA 

MIA-CH 

I 


One Way 


0-3 






3: NW 
CHI -BO 
S 


One Way 


P-3 






3: UA 

MSP-BO 

S 


One Way 
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TABLE 32 below lists slice-label -sets that are 
produced in this example, and as with itineraries and 
itinerary divisions, the faring process assigns each a 
numerical lafc>el . Many itineraries may be grouped into 
the same slice-label-set. For example, there are three 
different itinerary -divisions that are grouped into 
slice-label-set 1.3. TABLE 30 lists, for each slice- 
label-set, its backward-projection. This is the set of. 
multi-slice PU-labels that project onto previous slices. 



TABLE 32 



Slice 


Multi -Slice 
PU- Labels 


It inerar 

y 


Division 


Single- 
Slice 
PU- Labels 


Backward 
Projection 


■ 1 


1.1 {A-123} 


i.i 


1.1.1 


{} 


{} 


1 


1.2 {F-13} 


i.i 


1.1.1 


0 


{} 


1 


1.3 {} 


i.i 


1.1.1 


{i-d 


{} 






1.2 


1.2.1 


{G-l H-l} 








1.3 


1.3.1 


{J-l} 




1 


1.4 {B-13 
C-12} 


1.2 


1.2.1 


U 


{} 


1 


1.5 {B-13} 


1.2 


1.2.1 


{H-l} 


{> 


1 


1.6 {C-12} 


1.2 


1.2.1 


{Q-D 


{> 


2 


2.1 {A-123} 


2.1 


2.1.1 


{} 


{A-123} 






2.2 


2.2.1 


{} 




2 


2.2 {} 


2.1 


2.1.1 


{K-2} 


{} 






2.2 


2.2.2 


{L-2 M-2} 




2 


2.3 {C-12 
D-23} 


2.2 


2.2.2 


{} 


{C-12} 


2 


2.4 {C-12} 


2.2 


2.2.2 


{M-2} 


{C-12) 


2 


2.5 {D-23} 


2.2 


2.2.2 


{L-2} 


{} 


2 


2.6 {E-23} 


2.3 


2.3.1 


{} 


{} 


3 


3.1 {A-123} 


3.1 


3.1.1 


{} 


{A-123} 


3 


3.2 {D-23 
B-13} 


3.2 


3.2.1 


{} 


{D-23 B-13} 


3 


3.3 {D-23} 


3.2 


3.2.1 


{0-3} 


{D-23} 


3 


3.4 {B-13} 


3.2 


3.2.1 


{N-3> 


{B-13} 


3 


3-5 {} 


3.2 


3.2.1 


{N-3 0-3} 


{} 


3 


3.6 (E23 
F13) 


3.3 


3.3.1 


{} 


{E-23 F-13} 


3 


3.7 {E23} 


3.3 


3.3.1 


{P-3} 


{E-23} 
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Shown in the TABLE 3 3 below are lists for each 
slice of the open-label-sets, as well as their backward- 
5 links and their next-slice-projection. This last field 
is the subset of open PU-labels that project onto the 
subsequent slice. It is equal to the backward- 
projection of any slice-label-set that is part of a 
backward-link to the open-label-set. 
10 TABLE 33 



Slice 


Open - Label - Se t 


Next-Slice 
Projection 


Backward -Link 

Slice-Label -Set 


Backward -Li-nk 

Open- Label -Set 


0 


0.1 {} 


{} 






1 


1.1 {A- 123} 


{A-123 } 


1.1 {A-123} 


0.1 { } 


1 


1.2 {F-13} 


{} 


1.2 {F-13} 


o.i {} 


1 


1.3 {} 


{ } 


1.3 {} 


0.1 {} 


1 


1.4 {B-13 C- 
12} 


{C-12} 


1.4 {B-13 C-12} 


o.l {} :: 


1 


1.5 {B-13} 


{} 


1.5 {B-13} 


o.i {} 


1 


1.6 {C-12} 


{C-12} 


1.6 {C-12} 


0.1 { } 


2 


2.1 {A-123} 


{A-123} 


2.1 {A-123} 


1.1 {A-123} 


2 


2.2 {} 


{} 


2.2 {} 


1-1 {} 


2 


2.3 {D-23} 


{D-23} 


2.3 {C-12 D-23} 


1.6 {C-12} 








2.5 {D-23} 


1.3 {} 


2 


2.4 {E-23} 


{E-23} 


2.6 {E-23} 


1.3 {} 


2 


2.5 {D-23 F- 
13} 


{D-23 F- 
13} 


2.5 {D-23} 


1.2 {F-13} 


2 


2.6 {E-23 F- 
13} 


{E-23 F- 
13} 


2.6 {E-23} 


1.2 {F-13} 


2 


2.7 {F-13} 


{F-13} 


2.2 {} 


1.2 {F-13} 


2 


2.8 {D-23 B- 
13} 


{D-23 B- 
13} 


2.3 {C-12 D-23) 


1.4 {B-13 C-12} 








2.5 {D-23} 


1.5 {B-13} 


2 


2.9 {E-23 B- 
13} 


{E-23 B- 
13} 


2.6 {E-23} 


1.5 {B-13} 


2 


2.10 {B-13} 


{B-13) 


2.4 {C-12} 


1.4 {B-13 C-12} 








2-2 {} 


1.5 {B-13} 


3 


3.1 {} 


{} 


3.1 {A-123} 


2.1 {A-123} 








3.5 {} 


2.2 {} 








3.3 {D-23} 


2.3 {D-23} 








3.7 {E-23} 


2.4 {E-23} 








3.6 {E-23 F-13} 


2.6 {E-23 F-13} 








3.2 {D-23 B-13) 


2.8 {D-23 B-13} 








3.4 {B-13} 


2.10 {B-13} 
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Each open-label-set contains a set of PU-labels 
that are still "open", i.e., project onto a subsequent 
5 slice. For example, the PU- label C-12 does not appear 
in open-labei-sets from slice 2 or slice 3. In the 
pricing-graph, each open- label -set will be translated 
into an OR over the backward- 1 inks . The backward- links 
represent paths that lead to the open-label-set. Each 
10 is a pair (an AND) of a slice-label-set with an open- 
label -set from the previous slice. Because TABLE 3 3 is 
consistent, the backward-projection of any slice- label - 
set iri a link is equal to the next-slice-projection of 
the open- label -set in the link. Furthermore, the PU- 
IS labels in each open- label -set can be. constructed by V 
selecting any backward- link, taking the union of the PU- 
labels in the link's open-label -set and slice-label-set, 
and removing any PU-labels that do not project forward. 
If there is an empty open-label-set for the last 
20 slice, then pricing- solutions exist. This open- label - 

set provides the "root" of the pricing-graph, a . node that 
has a child for every link. Each of these links will 
become an AND of the slice- label-set and the previous 
open- label -set . In this way open-label-sets and slice- 
25 label -sets are used to produce the pricing-graph. 

FARE - COMB I NAB I L I TY RESTRICTIONS 

The linking procedure described above assumes that 
there are no restrictions on the mixing of priceable- 
30 unit -labels other than those imposed by itineraries. 
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This is not always the case. For example, although the 
various create- PUs-in-markets procedures described above 
apply f are-combinability checks, those checks include 
only restrictions on the fares that may coexist within a 
5 priceable-unj.t . These checks include ATPCO categories 
101, 102 and 103, but not category 104. The category- 10 
record-2s that are stored on fare-components may also 
include so called "end-on-end" f are-combinability 
restrictions. These restrictions constrain the fares 

10 within other priceable-units . One example of such an 
end-on-end f are-combinability constraint is that all 
fares within an entire journey must be published by the 
same airline as the fare with the constraint. 

Cross-priceable-unit constraints such as end-on-end 

15 f are-combinability restrictions complicate the process :.. 
of finding valid fares for itineraries. In general 
cross-priceable unit constrains can be very expensive to 
evaluate. These constraints can often be efficiently 
evaluated during the process that links the set of valid 

20 fares to the sets of flights to form a pricing solution. 
Below, an efficient approach for evaluating many common 
end-on-end f are-combinability restrictions is described. 

First, priceable-unit-labels are constructed in 
such a manner that all priceable-unit -cores within them 

25 share the same end-on-end combinability restrictions. 
This is reflected in the procedure partition- fare- 
components- into -sets, described previously. During the 
linking process each priceable-unit-label end-on-end 
f are-combinability restriction is applied to the fares 

30 in other priceable-unit-labels. This happens during the 
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initial stage of the linking process, in the execution 
of create- slice -label -sets . Create- slice- label -sets 
iterates over itinerary divisions, and for each 
division, iterates in an inner loop over covering sets 
5 of priceable-unit-labels. In this inner loop an end-to- 
end f are-combinability restriction attached to one 
priceable-unit -label -in the set can be applied to fares 
in other priceable-unit -labels within the set. If the 
restriction fails, the set of priceable-unit-labels is 
10 rejected. 

For this procedure it is desirable that every 
priceable-unit -label containing an end-on-end 
restriction projects onto all the slices that the 
restriction needs to be checked against. Some 
15 restrictions may only need to be checked against fares 
adjacent to the fare -component or priceable-unit 
containing the restriction, while others may need to be 
applied to every other priceable-unit in the entire 
journey. Hence, if a priceable-unit-label projects onto 
20 every slice, then its end-on-end restrictions can be 
applied to every other priceable-unit-label in a 
potential pricing- solution. 

But, if a priceable-unit-label projects onto only 
one slice (as a one-way priceable-unit-label would) 
25 while its restriction must be applied to priceable-units 
from several slices, then the restriction cannot be 
applied using the method described here. In such a case 
there are several options available. One is to reject 
the set of priceable-unit-labels currently under 
30 consideration. Another is to accept it, but mark it as 
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potentially requiring that any solution containing it 
must be split into several journeys (a "split ticket"). 

When a combinability record-2 is applied in this 
manner, the information available to it at any one time 

5 is a set of ^riceable-unit- labels that collectively 
cover a division of an itinerary (one of these 
priceable -unit -labels contains • the source record-2) . 
Each of these priceable-unit-labels reference one or 
more priceable-unit -cores , each of which in turn 

10 references one or more fares. It is these fares that 

are validated by the combinability record-2. It may be 
that some priceable-unit -cores from within a priceable- 
unit-label pass, while others fail. Several options are 
available in this ambiguous case: a new priceable-unit- 

15 label can be generated, referencing only those 

priceable-unit -cores that pass, or the entire priceable- 
unit -label can be rejected. The second is the more 
efficient option, though it may cause some valid 
pricing- solutions to be unnecessarily rejected. 

20 

CONSTRUCTING SLICE -LABEL -SETS 

Slice-label-sets are constructed during the process 
of producing open-label-sets 282, by the pseudo-code 
25 given below (TABLE 34) . This code is passed the set of 
itineraries for a slice. 

For each itinerary and each division within that 
itinerary, all possible sets of PU-labels are 
enumerated. Each set is partitioned into a set of 
30 multi-slice PU-labels and a set of single-slice PU- 



WO 00/02152 



PCT/US99/14961 



73 

labels. A unique slice-label-set is produced for each 
collection of multi-slice PU-labels. Within the slice- 
label-set are stored itinerary- label -holders . Each of 
these pairs an itinerary with a set of division-label - 
holders. Each division-label -holder pairs an itinerary 
division with a set of sets of single-slice PU-labels. 



TABLE 34 



create-siice-tabel-sets(itineraries) 

Subroutine diviston-PU-label-sets(drvision) 
// 

// Return a list of all the possible sets of PU-labels for this division. 
// 

Let PlWabel-sets = { 0 } 
For faring-atom in division 

Let new-PLMabel-sets = 0 

For PLMabet in faring-atom. priceable-unit-labels 

For previous-PU-label-set in previous-PU-IabeJ-sets 

new-PU-label-sets += postpend (previous-PU-label-set. PU-label) 
PU-label-sets = new-PU-label-sets 
retum(PU-labei-sets) 

Let slice-label-sets = 0 

For itinerary in itineraries 

For division in itinerary .divisions 

For PU-labels in division-PU-label-sets(division) 

Let multi-slice-PU-tabels = multi-slice-PU-labels(PU-iabe!s) 
Let single-slice-PLWabels = single-slice-PU-labels(PU-labels) 

Let slice-label-set = find(mu!U-slice-PU-labeis. slice-label-sets) 
If (slice-label-set = nil) 

slice-label-set = new-slice-labe!-set<) 

slice-label-setmulti-slice-PU-labets = multi-slice-PU-labels 

slice-label-setdivision-single-slice-labels = 0 
Let itinerary-label-holder = find(itinerary, siice-label-seLitinerary-label-holders) 
If (itinerary-label-holder = nil) 

itinerary-label-holder = new-itinerary-label-holder() 

itinerary-label-holder.itinerary = itinerary 

itinerary-label-holder.division-label-holders = Q 

slice-iabel-seLitinerary-label-holders += itinerary-label-holder 
Let division-label-holder = find(division. itinerary-label-holder.cJivislon-label-holders) 
If (division-label-holder = nil) 

division-label-holder = new-division-label-holder() 

division-JabeJ-holder.division = division 

divisiorMabel-holder.single-slice-label-sets = 0 

itinerary-4abel-holder.divisioin-iabel-ho)der3 += division-label-holder 
division-label-holder.single-stice-labet-sets *■= single-slice-PU-labels 

retum(slice-Jabel-sets) 
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CONSTRUCTING OPEN -LABEL -SETS 

Open- label -sets are constructed slice-by- slice , 
5 starting from a single, empty open-label-set. For each 
slice, the first step is to produce slice-label -sets 
using the procedure described above, and enumerate the 
current set of open-label-sets. For each open-label- 
set, the projection into the next slice is computed. 
10 All slice-label-sets with backward-projections equal to 
that next -slice-projection are used to create a new set 
of open multi-slice priceable-unit-labels , and from this 
a new open- label -set is produced. The pseudo code below 
in TABLE 3 5 describes this. 

15 

TABLE 3 5 

tink-itinenanesOtlnerary-sets) 

Subroutine projection(PU-Jabels, slice-number) 

// 

// Return those PLMabels that project onto this slice. 
// 

Let result = 0 

For PlMabel in PIMabels 

If (find(sllce-number. PIMabef.stice-numbers)) 
result += PlMabel ■ 

retum(result) 

Subroutine backward-projectton(PU-labels, slice-number) 

// 

// Return those PU-labets that project onto a previous slice. 
// 

Let result = 0 

For PU-label in PU-labels 

If (find-tf-tess-than(slice-number, PLMabel.slice-numbers)) 
result +=* PU-label 

retum(resutt) 

Subroutine forward-projection(PU-tabels, slice-number) 

// 

// Return those PU-labets that project onto a subsequent slice. 
// 

Let result = 0 

For PU-label in PU-labels 

If (find-if-greater-than<slice-number, PU-label. slice-numbers)) 
result ♦* PU-label 

retum(result) 

Let initial-open-label-set = new-open-label-set{) 
tnitial-open-*abel-set.open-PU-labels = 0 
initial-open-4ab«l-set.backward-Jinks = 0 
Let open-label-sets = ttst(lnUlal-open-4abel-set) 
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Let open-PLMabets = open-Jabel-setopen-PLMabeis 

Let next-slice-projection « proiection<open-PLMabels. slice-number) 

For slice-label-set in sllce-label-sets 

Let siice-PLMabeis =* slice4abel-s«tmuJti-slice-PLMabels 

If <next-stice-projection = bac*cwanl-proiection(slice-PU^abels, sUce-number) 

Let newnopen-PLMabels = forward-projection(union(slice-PU.iabets. open-PLMabels). 

stice-number) 

Let new-open-label-set = find(new-open-PLMabels. new-open-label-sets) 

If (new-open-Jabel-set = nil) 

new-op en -lab el-set a new-open-tabe4-set() 
new-open-label-setopen-PU-labels = new-open-PLMabels 
new-open-labef-setbackward-links = 0 

Let backward-link = new-backward-linkO 

backward-link.slice-iabet-set = slice-labet-set 

backward-link.open-iabel-set » open-label-set 

new-open-labei-seLbacxward-finks += backward-link 



open-labet-sets = new-cpen-label-sets 
slice-number += 1 
If (open-label-sets = 0) 
retum(nil) 

Else 

// Return the root open-labei-set. 
retum(frrst(apen-iabel-sets)) 



WO 00/02152 



PCT/US99/14961 



76 

PRICING GRAPH 

Referring now to FIG. 17, a pricing graph 38 1 (FIG. 
3) is produced containing logically combinable nodes 
that can be used to efficiently and compactly represent 
5 a set of pricing solutions 38 (FIG. 1) . The pricing 

graph 38 1 as used herein is a so-called directed acyclic 
graph although other types of representations could be 
used. For example, a grammar, could be used. 

The pricing graph 38' is constructed 300 from data 

10 structures 3 02 (summarized below in TABLE 3 6 and 

mentioned in conjunction with FIGS. 4A-4B) provided 
during the preceding processes. The data structures 
convert 3 04 to one or more nodes in the pricing graph. 
The open- label -set data structure becomes an OR node and 

15 its children are the converted versions of its backward 
links. Each backward link in the open label set is 
converted to an AND node. If a pricing object is 
shared, for example, a priceable unit core is shared 
between several priceable unit labels, then its 

20 counterpart nodes in the pricing graph will be shared so 
that the size of the pricing graph is not unnecessarily 
enlarged. The converted nodes are placed 3 06 in the 
pricing graph nodes. Terminal objects such as fares and 
itineraries undergo essentially no conversion. They are 

25 placed 308 into special terminal nodes with no children 
and are obtained from the various data structures that 
* have the pricing objects. 



30 
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TABLE 3 6 



Data- Structure 


Type 


Child Fields 


Type 






open- label - set 


OR 


backward- links (each a backward- link) . 


backward- link 


AND 


open -label -sec (an open- label- sec ) . 
slice-label-sec (a slice-label-sec ) . 


slice -label -set 


AND 
(OR) 


multi- slice- PU- labels (each a priceable- 
unit- label) . 

i cinerary -label -holders (each an itinerary- 
label -holder) . 

The it inerary- label -holders are puc into an 
OR and the OR is placed under che AND, which 
also includes all mulci-slice-PU-labels . 


ic inerary- label - 
holder 


AND 
(OR) 


icinerary (an itinerary) . 
division- label-holders (each a division- 
label -holder) . 

The division- label -holders are puc into an 
OR and the OR is placed in an AND with che 
itinerary. 


division- label - 
holder 


OR 

(AND) 


single -slice -P17- label -sets 
(each a sec of sets of PU-labels) . 
The inner sets are puc inco ANDs , and these 
are all embedded under an OR. 


priceable-unit- 
label 


OR 


priceable-unic-cores (each a priceable-unit- 
core) . 


priceable-unit- 
core 


AND 


fares (each a fare) . 

surcharges (each a surcharge, penalty, 
discount, ecc.) 


fares 


Term 




itinerary 


Term 




surcharge 


Term 





In cases where a node has only one child, there is 
no need to produce the node. Rather, a direct link can 
be passed to its child. This does not alter the 
interpretation of the pricing -graph, but can result in a 
smaller graph. 

The pseudo-code below TABLE 37 summarizes 
construction of the pricing graph, given the "root" open- 
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label-set that is the output of the linking process. 



TABLE .37 



create-pridng-graph(root-object) 
Let nodes « 0 

Subroutine ccnvert-object(object) 

// Convert the object and cache the result, so that nodes with multiple parents are shared 
Let node = find(object, nodes) 
If (node = nil) 

node = convert(object) 

nodes += node 
retum(node) 

Subroutine convert-objects (objects) 

// Convert the set of objects and return a set of nodes. 

Let result = 0 

For object in objects 

result ♦= convert-object(object) 
retum(result) 



Subroutine create-node(children, type) 

// Create a node of type type with children children, if there is more than one child. 
// Otherwise the node is unnecessary, and the only child is returned. 
If (tength(children) = 1) 

retum(first(child) 

Else 

Let node = new-node() 
node. type = type 
node. children = children 
node.terminal-object = nil 
retum(node) 
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TABLE 3 7 (cont . ) 



Subroutine convert(object) 

Let object-type = type(object) 

If (type - open-label-set) 

return (create-mxJe(convert^bjects(object.backward-links) t OR)) 
Else If (type = backward-link) 

retum(create-node(list(convert-object(objecLslice^abei-set), convert-object(objecLopen-label-set)). AND) 
Else If (type = stice-tabel-set) 

Let children = convert-obiects(object.mulU-slice-PU-labels) 

children += create-node(oonvert-obiects(objectitinerary-label-hotders), OR) 

retum(create-node(children t AND)) 
Else If (type = itinerary-labei-holder) 

Let children = convert-objects(objecidivision-labei-holders) 

children create-node(convert-objects(objecLitinerary) l OR) 

retum(create-node(children, AND)) 
Else If (type - division-label-holder) 

Let children = 0 

For singie-sfice-PU-label-set in objectsingle-slice-PLMabel-sets 

children += create-node(convert-objects(single-slice-PU-(abel-set). AND) 

retum(create-node(children, OR)) 
Else If (type = priceable-unit-label) 

retum<create^cde(convert-objects(object.priceableHjnit-cores), OR) 
Else If (type = priceable-unit-core) 

retum(create-node(append(convert-objects(object.fares)» convert-objects(objecLsurcharges)). AND) 
Else // object is a terminal. 

Let node * new-node() 

node, type = terminal 

node. children = 0 

node. terminal-object = object 

retum(node) 

retum(connvert-object(root-object)) 



The pricing graph 38' resulting from the search 
procedure 54 provides a compact way for representing a 
very large number of set of pricing solutions. By the 
5 above process, it is often possible to obtain a very 
large number of pricing solution components. Although 
the number of pricing solutions can be returned in the 
form of a simple list, this is not desirable. A very 
large number of pricing solutions can be difficult to 
10 manipulate, enumerate and interrogate and to 

transfer/transmit across a network since the amount of 
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data involved is very large. The pricing graph 38 1 
provides a more compact way of representing these 
pricing solutions. The compact representation of the 
range of set of pricing solutions is generated where 
5 choices are ^represented explicitly and redundancy is 
removed wherever possible. 

As mentioned above, the pricing graph 38 1 produced 
by the search procedure 54 includes three types of 
nodes. The first type of node is a node that represents 

10 choices called "LOGICAL OR" nodes. The second type of 
node is a node that represents collections referred to 
as "LOGICAL AND" nodes. A third type of node represented 
in the pricing graph is a terminal node that represents 
pricing objects. 

15 A data structure representation (TABLE 38) of ::: the 

nodes is set out below. Each node contains a "type", 
which specifies whether the node is an AND node, an OR 
node or a terminal node. The data structure also 
contains either list of children (if the node is an AND 

20 node or an OR node) or a terminal object (if the node is 
a terminal) . The node contains fields that store values 
used by algorithms that manipulate the pricing graph 
38'. 

25 TABLE 38 



Node fields 


Use 


type 


Either AND, OR or TERMINAL 


children 


A list of child-node9, if node is AND or OR. 


terminal - ob j ect 


A terminal -object such as a fare or itinerary, if 
the node is TERMINAL. 


Active? 


True or false, depending on whether the node is 
active. 


inner-value 
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The node's minimum possible inner- value. 


outer-value 


The node's minimum possible outer-value. 


total -value 


The node's minimum possible total -value. 


best-child 


For OR-nodes, the child with the least-positive 
inner- value . 



As mentioned above, the pricing graph 38 1 is a 
compact representation of a set of set of pricing 
solutions. The typical number, of set of pricing 
5 solutions represented by pricing graph ranges from tens 
of millions into hundreds of billions with the number of 
nodes in the graph ranging from thousands to tens of 
thousands. The pricing graph can be easily stored 
and/or transmitted over a network or other connection to 
10 a client and represents complete representation of all 
or substantially all of possible pricing solutions. 
Therefore, the pricing graph 38 1 can be used by a smart 
client without further intervention from the server 12. 

15 

MANIPULATING THE PRICING-GRAPH 

Referring now to FIG. 18, a high level illustration 
of a process 300 that operates on the pricing graph 38* 
tfypically as a client process 36 on the client computer 

20 system is shown. The process 300 includes a user query 
3 02 that passes parameters into a process 3 04 and a 
value function 306 to extract from the pricing graph 38* 
certain pricing solutions 308 that satisfy parameters 
specified by the user query 302. The extracted pricing 

25 solutions are returned as a list 308 or other 

representation. Generally the pricing solutions are 
displayed on the display 40. Display software 309 
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handles production of GUI's 41 to present the 
information . 

. The pricing solution list 3 03 will contain pricing 
solutions extracted from the pricing graph 38 1 in 
5 accordance with user specified parameters from the user 
query 3 02 using one of the processes 3 04 and one of the 
value functions 3 06. 

Referring now to FIG. 19, illustrative processes 
are shown. In particular, in response to the user query 

10 3 02, one of the processes is executed. The processes 
3 04 can comprise a find best "value" and pricing 
solutions associated with the value (e.g. , price) 
process 3 04a; find best "value" and pricing solutions 
associated with the value for "node" (e.g., find best 

15 price for a particular itinerary) process 304b; an ::: 
enumeration for "N" pricing solutions 3 04c; or an 
enumeration process that lists the pricing solutions 
according to some "value." Additional enumeration 
processes can' be provided to produce query results 

20 corresponding to different ways of looking at pricing 

solutions extracted from the pricing graph 38 1 . A node 
invalidating process 304e that invalidates selected 
nodes from contributing to a pricing solution is also 
included. 

25 Examples of each of these processes are set forth 

below. 

Efficient algorithms 304 are used for manipulating 
this representation to extract information of interest 
and to enumerate set of pricing solutions from the 
30 structure. For example, it is possible to quickly 
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extract the cheapest solution; to find the cheapest 
solution involving selected fares and itineraries; to 
verify whether any pricing solution remains if specific 
fares or itineraries are excluded; to enumerate 
5 solutions under various order ings and so forth. 

Furthermore, the representation is compact enough so 
that it can be efficiently stored and transmitted such 
as from the server to the client. One benefit, 
therefore, is that after a single fare search 54 in the 

10 server process 16, the server process 16 transfers the 
pricing graph 38 to the client process 36. The client 
process 3 6 can examine and manipulate the large space of 
pricing solutions represented in the pricing graph 38' 
without further interaction with the server process 18. 

15 For the set of pricing solutions represented by the 

pricing graph 38 1 to be useful, processes . are provided 
to extract pricing solutions from the graph and 
manipulate the set of pricing solutions, as depicted in 
FIG. 19. In general, each of the enumeration processes 

20 to be described operate on the pricing graph to extract 
pricing solutions from the pricing graph according to 
particular criteria that can be set, for example, by a 
client system 3 0c (FIG. 2) in response to a user query 
48 (FIG. 4) . Examples of user queries as well as a 

25 display representation for information extracted from 
the pricing graph will be described below. 

An example of an enumeration function enumerates 
pricing solutions in a specific order. For example, an 
enumeration function can enumerate the 100 cheapest 

30 pricing solutions represented by the pricing graph 38'. 
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A second, enumeration function can find extreme points 
of the set of pricing solutions. This can be used, for 
example, to find the most convenient pricing solution. 
In addition, a value function can specify a minimum 
5 value of some value over the set of pricing solutions 
that involve a particular node. One value function 
finds for each itinerary the cheapest pricing solution 
that involves that itinerary or the shortest total 
duration of any pricing solution that involves that 

10 itinerary. 

In addition, each of the above operations can be 
performed on a subset of the graph. For example, it may 
be desirable to enumerate the 100 cheapest solutions 
that involve a given itinerary or finding the most 

15 convenient solution that involves only refundable fares 
or includes only certain airlines or excludes certain 
airlines . 

VALUE FUNCTIONS 

20 Referring now to FIG. 19, many processes or 

operations on the pricing graph 38* use a value- 
.function, a function that operates on the terminal nodes 
of the pricing graph 38* and returns a numerical value 
that can be used to rank pricing-solutions. Examples of 

25 value -functions include price computed by summing the 
prices of fares (and penalties and surcharges) in a 
pricing-solution, duration, or convenience (that might 
be a mix of total travel -time with penalties for stops 
and airline-changes, for example) , or mixes of each. 

30 Many of the processes used to manipulate the 
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pricing graph 38' depend on a value- function being 
decomposable into the sum of a second function that is 
applied to individual terminal nodes in the pricing- 
graph. The "price value function" meets this 
5 requirement^ because the total price of a pricing- 
solution is equal to the sum of the prices of fares. 
Many expressions of convenience also meet this 
requirement, including those that can be computed as the 
sum of a function applied to individual itineraries . 
10 However, there are some value -functions that cannot be 
placed into this form. An example is a "convenience" 
function that checks whether travel in different slices 
is on the same airline. Such a function depends on all 
itineraries at once. 

15 In general, in the discussion below, the term node- 

value- function is used to refer to a function that is 
applied to individual nodes in the pricing-graph, and 
summed to produce the value of an entire itinerary. The 
term value- function is used for the more general case of 

20 a function that may or may not be decomposable into the 
sura of a node -value- function applied to each terminal in 
the pricing-graph. 

FINDING THE BEST PRICING SOLUTION 

25 The first process 304a is an example of one that 

finds extreme points of the set of pricing- solut ions , 
such as the cheapest pricing-solution. 

Assuming that it is desired to find a pricing- 
solution that minimizes some value-function that can be 
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decomposed into a node-value- function F, the best 
pricing solution could be found by enumerating all 
pricing- solutions and applying F to each of them. This 
is impractical because of the large number of set of 
5 pricing solutions. 

The Best Price algorithm 3 04a efficiently finds the 
cheapest (best) pri"ce by starting at the "bottom" of the 
pricing-graph 38 1 and constructing the best solution for 
each node by looking at the best solution of its 
10 children. In this way it works in one pass from the 
bottom of the graph to the top. At the end of the 
process the root node contains the best pricing solution 
for the entire pricing graph 38. 

The algorithm proceeds as follows: first, the nodes 
15 in the graph are ordered by depth and placed in a list, 
so that iterating over the list ensures that a child 
node is always encountered before its parent (s) . Then, 
iterating across the list, the best value of F is 
computed for each node, using the already- computed 
20 values of F for its children. At this point every node 
_in the graph is marked with its inner-value. The inner- 
value of a node is the best possible value of the 
function F on the set of (partial) pricing- solutions 
represented by the node. As inner-values are computed, 
25 for every OR node the child with the lowest inner-value 
is computed and stored. Finally, the best pricing 
solution can be constructed by starting at the root of 
the graph and collecting children. Whenever an OR node 
is encountered, the best child is chosen (the child with 
30 the lowest inner-value) . 
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If a node is a terminal fare or itinerary, then its 
inner-value is the value of F applied to the node. If 
the node is an AND, representing a combination, then the 
minimum value of F over the partial solutions it 
5 represents is the sum of the minimum values of F over 
the partial solutions represented by each of its 
children. If a node is an OR, representing a choice, 
then the minimum value of F over the partial solutions 
it represents is found by making the optimal choice of 
10 children, that is, the child with the minimum inner- 
value. So the inner-value of an OR is the minimum of 
the inner- values of its children. 

The pseudo-code in TABLE 3 8 summarizes the 
computation of inner-values. The function sort-nodes 

15 takes a root node and returns a list of all nodes under 
it, sorted by depth with the root node at the end. The 
procedure compute- inner- values takes in a sorted list of 
nodes as would be produced by sort -nodes, and a node- 
value- function . The procedure find-optimal -solution 

20 takes in a root-node and a node- value- function, calls 

sort-nodes and compute -inner- values to calculate inner- 
Values for all nodes in the pricing-graph, and 
constructs a pricing-solution. 
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TABLE 3 8 



sort-nodes(node) 
Let nodes = 0 
For child in node. children 

nodes = append(nodes, sort-nodes(child)) 
nodes += node 
retum(nodes) 

^compute-inner-values(sorted-nodes t node-value-function) 



For node in sorted-nodes 

If (node. type = terminal) 

node. inner- value = apply(node-value-function, node.terminal-object) 
Else If (node.type * OR) 

node.inner-value = infinity 
For child in node.children 

If (child.inner-value < node.inner-value) 
node.inner-value = child.inner-value 
node. best-child = child 
Else If (node.type = AND) 
node.inner-vatue = 0 
For child in node.children 

node.inner-value child.inner-value 

find-optima*-solution(root-node, node-value-function) 

Subroutine get-node-solution(node) 

If (node.type = terminal) 

re tum(list<node. terminal-object)) 
Else If (node.type = OR) 

retum(get-node-solution(node.best-child) 
Else If (node.type = AND) 

Let solution = 0 

For child in node.children 

solution = append(solution. get-node-solution(child)) 

retum(scHution) 



compute-inner-values<sort-nodes(root-node), node-value-function) 
retum(get-node-solution(root-node)) 
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FINDING MINIMUM VALUE 

Another procedure 3 04b finds, for each node, the 
best (i.e., minimum) value of some value- function over 
all the set of pricing solutions involving that node. 
5 Price function 3 06a finds for each itinerary, the 

cheapest price of any pricing solution that contains 
that itinerary. These values can be computed 
efficiently, if the value-function can be decomposed 
into a node -value -function. 

10 The best price value function 3 06a computes inner- 

values, as above, and computes for every node, an outer- 
value, equal to the minimum value contributed by all 
parts of the graph except that represented by the node . 
For each node, the minimum value of the value -function 

15 over all . solutions that involve the node > (i.e. , the 
total -value) is computed as the sum of that node's 
inner-value and outer-value. 

The outer- value and total -value of a node are 
computed in a manner very similar to the computation of 

20 the inner-value. In particular, the outer-value for 
each node is calculated starting from the root of the 
graph, that has an outer-value of 0. Each node 
propagates outer-values down to its children. An 0R- 
node passes its outer-value unchanged. An AND-node adds 

25 to its outer-value the inner-values of all children 

except that being propagated to. At every node, after 
the outer-value has been computed, the total -value is 
computed as the sum of the inner-value and outer-value. 

When outer-values are propagated from a node to its 

30 children, a minimum computation is performed. This is 
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because each child may have more than one parent, and 
its outer-value must be the minimum outer-value 
contributed by any parent. See TABLE 3 9 below. 

TABLE 3 9 

compute-outer-and-total-Values(root-node, node-value-function) 
// Sort nodes and computer inner-values. 
Let sorted-nodes = sort-nodes(root-node) 
cornpute-mner-values(sorted-nodes . node-value-function ) 

Let reversed-nodes = reverse(sorted-nodes) 



// Initialize all nodes to have outer-values of infinity. 
For node in reversed-nodes 

node. outer-value = infinity 

// Tut* fuOi-ttuutt iias dn Outtfi -value Ot G. 
first(reversed-nodes).outer-value = 0 

For node in reversed-nodes 

// Compute the total-value for the node, 
node.total-vaiue ~ node.inner-value + node.outer-value 

tf (node.type = OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node.chitdren 

child. outer-value = rninimum(chiid.outer-value. node.outer-value) 
Else if (node.type = AND) 

// For AND nodes, the outer-value is propagated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value, which is equaJ to the node's total-value minus the child's 
// inner-value. 
Forchild in node.children 

child. outer-value = minimum(child.outer-value, node.total-value - child. inner-value) 



INVALIDATING NODES 

It may be desirable to "invalidate" 3 04e certain 
nodes from the pricing-graph 38 f . For example, 

10 itineraries containing or not containing specified 

airlines could be marked as not participating in the 
above algorithms, enabling the algorithms to find the 
best solutions involving or not involving these 
itineraries. The above algorithms can be easily adapted 

15 to accommodate checking whether the node is valid. In 
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particular, the computation of inner-values, the first 
step in all the above algorithms, is modified to mark 
for every node .whether the node represents any valid 
partial pricing-solutions given a specific query 
parameter. This information can be used in the rest of 
the algorithms. Every terminal node contains a field 
"valid?" that is either true or false. The compute- 
inner-values procedure uses these values to set the 
"valid?" field for non- terminals . See TABLE 4 0 below: 

TABLE 4 0 



// Initialize ail nodes to have outer-values of infinity. 
For node in reversed-nodes 

node.outer-value = infinity 

// The root-node has an outer-value of 0. 
first(reversed-nodes).outer-value = 0 

For node in reversed-nodes 
If (node.vatid? = true) 



// Compute the total-value for the node, 
node.totat-value = node, inner-value + node.outer-value 



If (node.type = OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node. children 

child.outer-value = minimum(child. outer-value, node.outer-value) 
Else If (node.type = AND) 

// For AND nodes, the outer-value is propagated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value, which is equal to the node's total-value minus the child's 
// Inner-value. 
For child in node. children 

child.outer-value = minimum(child. outer-value, 

node.total-value - child. inner-value) 
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sort-nodes (node) ^ *" 

If (not(find(rode. nodes))) 

For child in node.children 

sort-nodes-inner(child) 

nodes +=node 

sort-nodes-inner(node); 

return (nodes) 

compute-inner-values(sorted-nodes, node-value-function) 

For node in sorted-nodes 

If (node.type = terminal) 

node.inner-value = appiy(node-value-function, node.terminal-object) 
Else If (node.type = OR) 

A node.inner-value = infinity 
node.valid? = false 
For child in node.children 

If (child.valid? = true and child.inner-vatue < node.inner-value) 
node.inner-value = child .inner-value 
node. best-child = child 
node.valid? = true 
Else If (node.type = AND) 
node.inner-value = 0 
node.valid? = true 
For child in node.children 
If (child.valid? = true) 

node.inner-value += child.inner-value 

Else 

node.valid? » false 

ftnd-optimal-solution(root-node. node-value-function) 

Subroutine get-node-solution(node) 

If (node.type = terminal) 

retum(list(node.terminal-obiect)) 

Else If (node.type = OR) 

retum(get-node-solution(node.best-child) 

Else If (node.type = AND) 
Let solution = 0 
For child in node.children 

solution = append(sotuUon t get-node-solution(child)) 
return(solution) 

compute-inner-values(sort-nodes(root-node). node-value-function) 

if (root-node.valid? = true) 

retum(get-node-solution(root-node)) 

Else 

retum(nil) 

compute-outer-and-total-values(root-node, node-value-function) 

// Sort nodes and computer inner-values. 
Let sorted-nodes = sort-nodes (root-node) 
computeHnner-values(sorted-nodes. node-value-function) 

Let reversed-nodes = reverse(sorted-nodes) 
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// Initialize all nodes to have outer-values of infinity ; 
For node in reversed-nodes 

node.outer-value = infinity 

// The root-node has an outer-value of 0. 
first(reversed-nodes).outer-value = 0 

For node in reversed-nodes 
If (node. valid? = true) 



// Compute the total-value for the node. 

node, total-value = node.inner-vaJue + node.outer-value 

If (node.type = OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node.children 

child.outer-value = minimum(child.outer-vaJue. node.outer-value) 
Else If (node.type = AND) 

// For AND nodes, the outer-value is propagated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value* which is equal to the node's total-value minus the child's 
// inner-value. 
For child in node.children 

child.outer-value « minirnum(chitd.outer-value. 

node.total-value - child.inner-value) 
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ENUMERATING PRICING SOLUTIONS 

It is often desirable to arbitrarily enumerate many 
pricing solutions: the best, the second-best, the third- 
best, etc. 

The enumeration algorithm 3 04c maintains a queue of 
partial-solutions, ordered by the lowest possible total 
value of the value- function over all complete solutions 
that contain the partial -solution. At the start of the 
search, a single partial solution is constructed from 
the root node of the pricing-graph 38' . At each step 
the best partial-solution is dequeued, and expanded. 
Each partial-solution has a set of non-terminal nodes 
and a set of terminal objects. A partial-solution is 
expanded by selecting a non-terminal node and 
substituting the node's children (all of its children in 
the case of an AND, one of its children in the case of 
an OR) - If a dequeued partial -solution contains only 
terminal objects, it is complete, and is returned. This 
process continues until the desired number of pricing- 
solutions that can be specified by a user has been 
produced - 

The algorithm can accommodate value- functions that 
cannot be decomposed into the sum of a node-value- 
function. It does this by applying a second penalty- 
value- function to partial pricing- solutions as it 
constructs them. This function returns a non-negative 
number when given a new terminal object and existing set 
of terminal objects. The number is added to the values 
produced by the normal node -value -function. If the 
30 number is positive, it acts as a penalty. An example of 
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how this could be used is for the case where a penalty 
is applied if travel in two slices is on different 
airlines. The penalty-value- function would return a 
(positive) penalty if the terminal was an itinerary, and 
5 the set of existing terminals contained an itinerary 
with travel on different airlines. Otherwise it would 
return 0. See TABLE 41 below. 

TABLE 41 



compute-inner-values(sorted-nodes. node-value-function) 
For node in sorted-nodes 

If (node.type » terminal) 

node.inner-value = apply(node-value-function, node.terminal-object) 
Else If (node.type = OR) 

node.inner-value = infinity 

node.valid? = false 

For child in node.children 

If (child. valid? = true and child. inner-value < node. inner-value) 
node.inner-value = child. inner-value 
node. best-child = child 
node.valid? = true 
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Else If (node.type = AND) 
node.inner-value » 0 
node.valid? = true 
For child in node.children 

If (child.valid? = true) 

node.inner-value += child.inner-value 

Else 

node.valid? = false 



fmd-optimal-sotution(root-node. node-value-function) 

Subroutine get-node-solution(node) 

If (node.type = terminal) 

retum(list(node.tenninal-object)) 

Else If (node.type _= OR) 

return<get-node-solution(node.best-daughter) 

Else If (node.type = AND) 
Let solution = 0 
For child in node.children 

solution = append(solution. get-node-solution(child)) 
retum(solution) 

compute-inner-values(sort-nodes(root-node), node-value-function) 

If (root-node.valid? = true) 

retum(get-node-solution(root-node)) 

Else 

retum(nil) 

compute-outer-and-total-values(root-node. node-value-function) 

// Sort nodes and computer inner-values. 
Let sorted-nodes = sort-nodes(root-node) 
compute-inner-values(sorted-nodes, node-value-function) 

Let reversed-nodes = reverse(sorted-nodes) 

// Initialize all nodes to have outer-values of infinity. 
For node in reversed-nodes 

node.outer-value = infinity 

// The root-node has an outer-value of 0. 
first(reversed-nodes).outer-vatue - 0 

For node in reversed-nodes 

If (node.valid? = true) 



// Compute the total-value for the nnde. 
node.total-value = node.inner-value * node.outer-value 



If (node.type = OR) . . 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node.children 

child.outer-value = minimum(child.outer-value, node.outer-value) 

Else iHno^e^pe^^ )^ Quterva|ue ^ propa g ated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value, which is equal to the node's total-value minus the child s 
// inner-value. 
For child in node.children 

child.outer-value = minimum<child.outer-value, 

node. total-value - child.inner-value) 
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Referring now to FIG. 20, a window 3 50 that is part of a 
graphical user interface of the client process 3 6 (FIG. 
3) is shown. The graphical user interface permits the 
user to access inter alia the enumeration processes 304, 
5 value functions 306 and invalidate routine 307. The 
graphical user interface has user selectable controls 
352 such as "origin" and "destination". There are also 
controls for selecting time and date. In addition, 
there are controls 352 that specify "slices" of a 

10 journey. The user enters values corresponding to 

origin, destination, dates and time by selecting an 
appropriate one of the controls. The origin and 
destination controls 3 52 invoke a query window (FIG. 21) 
where the user can enter a value . After the origin 

15 destination and preferably date and time information are 
entered, a user control "GO" becomes activated. Pressing 
the "GO" button will, for an initial query, send the 
query to the server process 18. The server process 
handles the query and initiates the server process 18. 

20 The server process 18 returns to the client process 3 6 
a set of pricing solutions in a compact representation 
such as the pricing graph 3 8' . 

Referring now to FIG. 21, a query entry window 3 60 
is shown. The query entry window 360 is produced by 

25 activating either the ORIGIN or DESTINATION controls 3 52 
in the window 350. The query window 360 includes a user 
entry area 3 61 for entering a destination code or origin 
code (as appropriate) such as a three letter airport 
code or a location such as a city, region or country 

30 (e.g., Turkey). Region 364 depicts a listing of 
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airports in a region about the location entered in area 
361, whereas area 364 lists origins and destinations of 
a flight slice (none shown) that has been selected for 
the query. In addition, in the entry area 3 61 the user 
5 can enter more than one airport or region. The query 
can be constructed, therefore, with two or more origins 
and destinations appearing in each slice of a journey 
and the pricing solution would be determined for the 
various combinations. 
10 Referring now to FIG. 22, a window 370 is 

illustrated. Window 370 appears after a user query 
input to the server process 18 producing the pricing 
graph 38' that is sent to the client process 36 (FIG. 
3). Window 370 is an example of a single slice journey. 
15 Since window 370 depicts a one-way (i. e : , single slice 
journey) , only controls 352 corresponding to the first 
slice are shown as activated with information about the 
slice. Window 370 includes the same controls or buttons 
3 52, as described above with respect to window 3 50. The 
20 window 370 also includes a series of user preference 
controls 354, here "Nonstop", "Direct", "Online (on the 
-same airline)" and "Select" shown as not activated and 
"1st class", "2nd class" and "Refundable" shown activated. 
The Nonstop, Direct and Online controls when selected 
25 by a user will eliminate all components from the pricing 
solution that do not correspond to nonstop, direct or 
online flights. A select control operates in 
conjunction with the user marking one or more potential 
pricing solutions such that the numbers which appear 
30 shaded out are activated. When one or more of the 
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pricing solutions are activated and the select button is 
pressed, the client process extracts pricing solutions 
from the pricing graph. The "1st class", "2nd class" and 
"Refundable" controls when activated eliminate fares that 
5 do not correspond to these classes of travel. 

The window 370 also includes a listing 372 of 
airports involved in the results provided from the 
pricing graph 38 f , as well as, a listing 374 of 
airlines . 

10 The window 3 70 has a graphical region that provides 

a visual representation of pricing solutions extracted 
from the pricing graph 3 8'. One preferred 
representation of the pricing solution is a horizontal 
bar graph 376; The itineraries are ordered by 

15 increasing total fare with each entry 376a of the bar.. . 
graph corresponding to a set of flight segments on 
airlines that provide travel from the origin (e.g., 
'ESB') to the destination (e.g., SAN, San Diego 
International Airport) on airlines coded in accordance 

20 with the legends for the airline in listing 374 with 
stopovers denoted by airports. The bar graph 
representation displays a metric of the pricing solution 
in a graph format. Thus, as' shown for the first entry 
376a, there are two legs 377a, 377b on airline "TK" with 

25 a stopover 3 77c at airport "JFK" and two legs 377d and 
3 77e on airline "HP" arriving in San Diego (SAN) . As 
shown in FIG. 22, twenty-one possible solutions are 
represented in the horizontal bar graph ordered by 
increasing total fare. This typically represents a 

30 small fraction of the total number of pricing solutions 
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that may be represented by the pricing graph 38 ! . Other 
ones, if they exist, can be revealed by manipulation of 
a scroll bar 402. 

Referring now to FIG. 23, a window 380 illustrates 
5 a sample pricing solution including an itinerary 3 82 and 
fares 384. In this embodiment, such a window is produced 
by double-clicking 

on an itinerary such as 376a. Such a pricing solution is 
extracted from the pricing-graph 38' by invalidating 

10 304e all other itineraries in the same slice and then 
using procedure 3 04a to find the single cheapest 
remaining pricing-solution. The window 380 illustrates 
the sample outbound itinerary 382 with fares 384. The 
itinerary 3 82 can be selected, for example, by double 

15 clicking on the itinerary or by using the right button 
of a computer mouse and so forth. For example, what is 
displayed in this interface are the itineraries (which 
are TERMINAL 

NODES in the pricing graph 38 f ) along with their 
20 associated "lowest prices" that are computed by running 
algorithm 3 04b (with value function such that it 
computes for every node in the graph the lowest total 
price for any pricing solution involving the node. 

Referring now to FIG. 24, a second example of a 
25 window 3 90 containing pricing solutions is shown. 
Window 3 90 illustrates a round trip journey between 
Boston (BOS) and San Diego (SAN) . The window 3 90 
includes a section 380 including user controls 352 that 
permit user entry and modification of the results in the 
30 window as described above in conjunction with FIG. 22. 
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Here, however, controls are shown activated for both 
slice 1 and slice 2 of the journey. 

The window also includes the airport 3 72 and 
airline lists 374 and a graphical representation 400 of 
5 information (e.g., itineraries) with a subsection 402 
corresponding to outbound or first slice information 
(e.g., itineraries) and section 404 corresponding to 
inbound or second sTice information. Each graphical 
section 402, 404 is a horizontal bar graph and includes 

10 scroll bar controls 403 and 405, respectively. In 
addition, the window also includes user preference 
controls 3 54 shown activated for the first and the 
second slices of the journey. 

In a similar manner as discussed in conjunction 

15 with FIG. .23, . double clicking or otherwise . selecting an 
illustrative 

ITINERARY, for example, the first ITINERARY 3 92a will 
produce an itinerary window 410 (FIG. 25) that depicts 
information corresponding to the selected outbound 

20 itinerary 412 as well as. information for possible return 
itineraries 414 selected in accordance with the current 
outbound itinerary. The window 405 also includes fare 
information 416. 

Referring now to Fig. 26, a window 390' is shown. 

25 This window depicts a subset of the set of pricing 

solutions represented by the pricing graph as displayed 
in window 390 (FIG. 24) . The subset is selected by 
activating the "Select" button and highlighting a pricing 
solution (e.g., 392g, FIG. 24). The window 390' depicts 

30 possible return itineraries that can be matched with the 
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selected outbound itinerary 392g and the corresponding 
total fares for the itinerary. This operation modifies 
the pricing solutions and is performed within the client 
process 36. The client process uses the node 
invalidating function described in conjunction with FIG. 



19 . 



10 



15 



20 



25 



30 



Another process that can use the node invalidated 
function 307 described in conjunction with FIG. 19 would 
permit the user to point and click at certain airports 
and/or airlines represented as icons in fields 3 90 and 
392. in one mode, by selecting airline and/or airport 
pricing solutions that do not include the selected 
airline or airports are not extracted from the pricing 
graph 38'. In an alternate mode, selecting an airline 
or airport does not extract solutions containing the 
selected airline and/or airport from the pricing graph. 

The pricing graph can be viewed in other ways 
through the activation of the pull down menus shown in 
any of FIGS. 22, 24 and 26. For example, as shown in 
FIG. 22, there are four pull down menus "refresh", 
"outbound display", "return display" and "search 
properties." The refresh display will permit storing 
queries and permit a user to refresh the display. The 
outbound display menu will permit the user to resort the 
data according to any one of a number of 
characteristics. Example characteristics include, but 
are not necessarily limited to. cost, duration, 
departure time, arrival time, number of legs, number of 
segments and so forth. The outbound display can also be 
adjusted to allow a user to change the horizontal axis 
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to a time or duration axis as well as change the 
itinerary size to have it displayed small or large. A 
similar arrangement is provided for the return display. 
The search properties allow a user to conduct a faring 
5 search by computing fares or not computing fares, that 
is, by providing complete pricing solutions or merely 
just activating the schedule portion of the server 
process 18. The search properties also permit the user 
to search by legs or segments, specify a search time, a 
10 number of itineraries and number of extra itineraries to 
discard . 

Each of the display options referred to above make 
use of one or more of the value functions and processes 
described in conjunction with FIG. 19 and permitting the 

15 client process to extract or manipulate the pricing 

graph 38' . Accordingly, the pull down menus as well as 
the other controls on the graphical user interface are 
the user interface to the "value" functions and 
enumeration processes described above. 

20 Referring now to FIG. 27, a window 500 is shown. 

The window 500 includes an ensemble of travel options 
depicted as a histogram 502. The histogram 502 is a 
plot of an metric or option such as time as the x axis 
versus the number of itineraries on the y axis. 

25 Portions of the histogram representation can be selected 
and the processes above will invalidate all travel node 
that are not selected. These will provide corresponding 
changes in a bar graph representation 504 disposed below 
the histogram 502. This will also affect a list 

30 airports 506 by possible changing a visual appearance of 
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icons in the list 506. 

It is to be understood that while the invention has 
been described in conjunction with the detailed 
description thereof, the foregoing description is 
intended to illustrate and not limit the scope of the 
invention, which is defined by the scope of the appended 
claims. Other aspects, advantages, and modifications 
are within the scope of the following claims. 



What is claimed is: 
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CLAIMS 

1. A method executed in a computer system comprising: 
parsing at least one itinerary set into faring 
5 atoms that correspond to one or more travel unit 
segments spanned by a single fare; and 

applying rules to the faring atoms to produce fare 

components. 

10 2. The method of claim 1 wherein faring atoms are 
shared across itineraries. 

3. The method of claim 2 further comprising: 
constructing from the fare components a set of 

15 fares that are valid for and associated with the at 
least one itinerary set. 

4. The method of claim 3 wherein constructing a set of 
fares further comprises : 

20 constructing priceable units from the fare 

components ; and 

linking itineraries and priceable units^ into 

pricing solutions . 

25 5. The method of claim 2 wherein the pricing solutions 
correspond to the set of valid fares and information 
linking the set of valid fares to segments of the 
j ourney . 



30 



6. The method of claim 2 wherein linking itineraries 
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and priced units. — ^" linkin9 "77 leS 
and prioeable units through a data ~ 8 that 

represents '« ° f PriCin9 SOlUCi ° nS 10 3 C ^ 



form. 



5 7 . The method of claim 6 wherein applying rules 

further comprises; ^ ±f ^ 

deferring applying a rule co 
ru le references infection outside of the faring atom, 

10 ^ applying deferred rules when all fare components 

for evaluating the ruie have heen delivered to the fare. 

8 The method o£ claim 3 wherein parsing of 
l5 itineraries into faring atoms further comprises, 

grouping faring atoms by faring markets, and 
partitioning itineraries into divisions of faring 



atoms . 



20 9. The method of claim 3 wherein partitioning 
itineraries further comprises: 

splitting sequences of legs of itineraries into 
individual faring atoms if the legs are on a same 



airline . 



25 



10 The method of claim S wherein the pricing solutions 

represented in the compact form are represented as a 
graph type data structure having substantially fewer 
codes than pricing solutions represented by the data 



30 structure . 
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11. The method of claim 1 wherein the method is 
executed as a server process that determines travel 
planning information in response to travel request 
5 information from a client process that receives said 
travel planning information, said client process 
comprising : 

manipulating the travel planning information. 

10 12. The method of claim 11 wherein manipulating the 

travel planning information is performed in accordance 
with at least one user preference input, and further 
comprises 

producing a set of travel planning information by 
15 fare in accordance with the at least one user, preference 
input . 

13 . The method of claim 12 wherein producing further 
comprises sorting said travel planning information 

20 by lowest price . 

14. The method of claim 11 wherein manipulating further 
comprises : 

finding for the set of pricing solutions a pricing 
25 solution that optimizes a value function. 

15. The method of claim 14 wherein finding a value 
function finds for a travel option a best travel option 
involving an itinerary. 



30 
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16 . The method of claim 11 wherein manipulating further 
comprises : 

enumerating a subset o£ the set of pricing 
solutions in accordance with a user specified preference 
based on the set of pricing solutions. 

17 . The method o£ claim 16 wherein enumerating further 

comprises: 

pruning from the set: of pricing solutions, a set 
solutions that do not correspond to a user 



10 pricing 

preference 



>thod of claim 1 wherein applying rules 



18 . The me 
further comprises 
15 applying a 

determine i 
and 

■suits of applying the rule 



fare rule for a fare to an itinerary to 
f the fare can' be used with the itinerary ; 



storing res 



20 19- The method of claim 18 further comprising: 

determining for a subsequent application of the 
fare rule whether there is a result that corresponds to 
a previous application of the fare rule to be applied to 
a fare component and, if there is a stored result, 

25 return the stored result. 

20. The method of claim 19 wherein if the rule does not 

j- ^„ ro H result, further comprising 
have a corresponding stored result, 

applying the rule to the itinerary and storing the 
30 result of applying of the rule. 
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21. The method of claim 4 wherein constructing 
priceable units further comprises: 

enumerating a collection of faring markets; 
5 enumerating collections of sets of faring 

components by selecting sets of fare components for each 
faring market; 

enumerating collections of faring components by- 
operating on sets of fare components to evaluate 
10 deferred record-2's on collections of fare components; 
and 

representing the enumerated collections of faring 
components by priceable unit labels and priceable unit 
cores . 

15 

22. The method of claim 21 wherein enumerating 
collections of faring markets further comprises: 

enumerating said collections of faring markets in 
accordance with the type of priceable units that are 
20 constructed. 

23 . The method of claim 22 wherein said typje of 
priceable units are a one-way priceable unit, a round 
trip priceable unit, an open jaw priceable unit, or a 

25 circle trip priceable unit. 

24. The method of claim 23 wherein said enumerating of 
collections of sets of faring components by applying 
deferred record- 2' s further comprises applying deferred. 

30 record-2 's to the collection of fare components. 
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25. The method of claim 11 wherein the client process 
further comprises : 

generating a graphical user interface, said 
graphical user interface having a graphic region that 
displays a metric of the itinerary information in a 
graph representation with the metric associated with an 
executed user query. 

26. The method of claim 25 further comprising: 

specifying information in a user query section of 

the graphical user interface; 

representing in a field comprised of a plurality of 

icons airlines that are associated with itineraries in 

the graph representation. 



27. The method of claim 3 further comprising: 

representing the set of fares in a data structure 

20 comprising : 

a first plurality of choice nodes that 
represent exclusive pricing solutions; 

a second plurality of combining nodes that 
represent collective pricing solutions; and 
25 a third plurality of terminal nodes that 

represent pricing objects. 

28. The method of claim 27 wherein said pricing objects 
of the third plurality of terminal nodes comprise 
30 pricing objects that include fares. 
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29. The method of claim 27 wherein said pricing objects 
of the third plurality of terminal nodes comprise 
pricing objects that include itineraries. 

5 30. The method of claim 27 wherein said third plurality 
of terminal nodes comprise pricing objects that include 
one or more of itineraries, routes, fares, prices, 
booking codes, surcharges, taxes or rules/regulations. 

10 31. The method of claim 27 wherein said third plurality 
of terminal nodes comprise a field having a value to 
indicate whether the node is valid or invalid. 

32. The method of claim 27 wherein representing further 
15 comprises: 

combining subsequent nodes based on values in the 
combining nodes to produce a pricing solution. 

33. A computer program product residing on a computer 
20 readable medium for producing comprises instructions for 

causing a computer to: 

parse at least one itinerary set into faring atoms 
that correspond to one or more travel unit segments 
spanned by a single fare; and 
25 apply rules to the faring atoms to produce fare 

components. 

34. The computer program product of claim 33 wherein 
faring atoms are shared across itineraries. 

30 
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35. The computer program product of claim 34 further 
comprising instructions for causing a computer to: 

construct from the fare components a set of fares 
that are valid for and associated with the at least one 
5 itinerary set. 

36. The computer program product of claim 35 wherein 
instructions to construct a set of fares further 
comprises instructions to: 

construct priceable units from the fare components; 

and 

link itineraries and priceable units into pricing 
solutions . 

37. The computer program product of claim 36 wherein 
the pricing solutions correspond to the set of valid 
fares and information linking the set of valid fares, to 
segments of the journey. 



10 



15 



20 



38. The computer program product of claim 36 wherein 
instructions to link itineraries and priceable units, 
comprises instructions to link the itineraries and 
priceable units through a data structure that represents 
the set of pricing solutions in a compact form. 

25 39. The computer program product of claim 38 wherein 
instructions to apply rules further comprises 
instructions to: 

defer applying a rule to a faring atom if the rule 
references information outside of the faring atom; and 

30 apply deferred rules when all fare components for 
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evaluating the rule have been delivered to the fare. 

40. The computer program product of claim 33 wherein 
instructions to parse itineraries into faring atoms 
5 further comprises: 

group faring atoms by faring markets; and 
partition itineraries into divisions of faring 
atoms . 

10 41. The computer program product of claim 36 wherein 
the pricing solutions represented in the compact form 
are represented as a graph type data structure having 
substantially fewer codes than pricing solutions 
represented by the data structure. 

15 

42. The computer program product of claim 33 wherein 
the product is executed as a server process that 
determines travel planning information in response to 
travel request information from a client process that 
20 receives said 'travel planning information, said client 
process comprising instructions to cause a client 
computer to : 

manipulate the travel planning information. 

25 43. The computer program product of claim 51 wherein 
instructions to manipulate the travel planning 
information are in accordance with at least one user 
preference input, and further comprises instructions to: 
produce a set of travel planning information by 

30 fare in accordance with the at least one user preference 
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input . 

44. The computer program product of claim 52 wherein 
instructions to produce further comprises instructions 

5 to: 

sort said travel planning information by lowest 
price . 

45. The computer program product of claim 51 wherein 
10 instructions to manipulate further comprise instructions 
to: 

find for the set of pricing solutions a pricing 
solution that optimizes a value function. 

15 46. The computer program product of claim 54 wherein 

instructions to find a value function finds for a travel 
option a best travel option involving an itinerary. 

47. The computer program product of claim 51 wherein 
20 instructions to manipulate further comprise instructions 
to: 

enumerate a subset of the set of pricing solutions 
in accordance with a user specified preference based on 
the set of pricing solutions. 

25 

48. The computer program product of claim 56 wherein 
instructions to enumerate further comprise instructions 
to: 

prune from the set of pricing solutions, a set of 
30 pricing solutions that do not correspond to a user 
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preference. 

49. The computer program product of claim 33 wherein 
instructions to apply rules further comprise 
instructions to: 
5 apply a fare rule for a fare to an itinerary to 

determine if* the fare can be used with the itinerary; 
and 

store results of applying the rule. 

10 50. The computer program product of claim 58 further 

comprising instruction to: 

determine for a subsequent application of the fare 

rule whether there is a result that corresponds to a 

previous application of the fare rule to be applied to a 
15. fare component and, if there is a stored result., return. 

the stored result. 



51. The computer program product of claim 36 wherein 
instructions to construct priceable units further 
20 comprise instructions to: 

enumerate a collection of faring markets; 

enumerate collections of sets of faring components 
by selecting sees of fare components for each faring 
market ; 

25. enumerate collections of faring components by 

operating on sets of fare components to evaluate 
deferred record-2's on collections of fare components; 
and 

represent the enumerated collections of faring 
30 components by priceable unit labels and priceable unit 
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cores . 

52. The computer program product of claim 60 wherein 
instructions to enumerate collections of faring markets 
5 further comprise instructions to: 

enumerate said collections of faring markets in 
accordance with the type of priceable units that are 
constructed. 

10 53. The computer program product of claim 61 wherein 
said type of priceable units are a one-way priceable 
unit, a round trip priceable unit, an open jaw priceable 
unit, or a circle trip priceable unit. 

15 54. The computer program product of claim 61 wherein 

instructions tod enumerate collections of sets of faring 
components by applying deferred record-2's further 
comprise instructions to: 

apply deferred record-2 's to the collection of fare 

20 components. 

-55. The computer program product of claim 51 wherein 
the client process further comprises instructions to: 
25 generate -a graphical user interface, said graphical 

user interface having a graphic region that displays a 
metric of the itinerary information in a graph 
representation with the metric associated with an 
executed user query. 

30 

56 . The computer program product of claim 64 further 
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comprising instructions to: 

specify information in a user query section of the 
graphical user interface; 

represent in a field comprised of a plurality of 
5 icons airlines that are associated with itineraries in 
the graph representation. 

57. The computer program product of claim 53 further 
comprising instructions to represent the set of fares in 

10 a data structure comprising: 

a first plurality of choice nodes that 
represent exclusive pricing solutions; 

a second plurality of combining nodes that 
represent collective pricing solutions; and 
15 . a third plurality of terminal nodes that, 

represent pricing objects. 

58. A computer system for determining pricing solutions 
comprises : 

a computer ; and 
20 a computer readable medium storing a computer 

program that causes the computer to: 

parse at least one itinerary set into faring atoms 
that correspond to one or more travel unit segments 
spanned by a single fare; and 
25 apply rules to. the faring atoms to produce fare 

components . 

59. The computer system of claim 67 wherein the 
computer program product operates on faring atoms are 

30 shared across itineraries. 
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60. The computer system of claim 67 wherein the 
computer program product further comprising instructions 
for causing a computer to: 

5 construct from the fare components a set of fares 

that are valid for and associated with the at least one 
itinerary set . 

61. The computer system of claim 67 wherein the 

10 computer program product that comprises instructions to 
construct a set of fares further comprises instructions 
to: 

construct priceable units from the fare components; 

and 

15.. link itineraries and priceable units into pricing 

solutions. 
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